Why can't we just be in insert mode constantly and use Ctrl+something for all the commands? Also use Shift+arrows to select text?
If you have any issues with RSI, then vim is by far the best editor (especially the GUI mode version).
The command mode allows you to formulate in your mind what you want to do, and accomplish it in the minimum possible key strokes. This is important because your brain won't wear out like your joints and tendons can. The command mode usually allows you to specify repeat counts to avoid repeatedly mashing keys. It lets you make common text selections such as words, nested brackets, statements, etc with a couple of key strokes. It also allows you to create macros on the fly and repeat previous commands further cut down on repetition.
I find that reaching for the arrow keys puts my wrists at an awkward angle which induces more stress. Having to pound on them repeatedly while holding down various combinations of control keys makes things worse. (To address a common complaint with vim, I've added a mapping of Alt+F to ESC, so I don't have to reach up for that key if I don't want to.)
I probably spend more time in command mode than insert mode when I'm using vim to write code. That says to me that keeping an editor always stuck in insert mode may not be the best idea.
If play your boss and I exit with ':q', no problem. Your version is still there. If I exit with ':wq', vim says: "E45: 'readonly' option is set (add ! to override)" If I exit with ':wq!', vim says: "WARNING: The file has been changed since reading it!!! Do you really want to write to it (y/n)?"
So I conclude that one of the following is likely the case: a) your boss is was an idiot who would ignore a message ending with three exclamation points b) you boss installed a bizarre custom vim config file that somehow allowed silent overwrites of modified files from readonly mode c) your story is a fabricated troll
You use an H1B when you want the best guy, not when you want some low-cost faceless drone.
So now you get the "best guy" for the cost of a faceless drone plus some nominal administrative overhead. That's still much cheaper than having to get a "best guy" by a more conventional route, such as enticing the top staff of your competitors to come work for you with higher pay.
Moreover, you focus on a single case. However, in aggregate, there is no doubt that increasing the supply of workers for a particular field will lower the average salary paid for everyone. So companies can hire everyone at lower salaries.
Personally, if I have to divide up five children between two parents, I don't consider 2.5 to be an acceptable answer.
Acceptable to you or not, that's how it would be done physically.
Your acceptable solution involves a discrete math system. That's fine, but the safety of those children still shouldn't magically depend on whether you allocated them as Python ints or floats.
In the real world, 5 / 2 == 2.5. This is true whether the operands are integers or floats.
In some discrete math systems, 5 / 2 == 2.
A language has no way to really know what kind of problem you are working on and which calculation would be more appropriate. Python 2 made the assumption that if you fed in two integers, then you were working in a discrete math system. This turns out to not usually be the case, and was a source of surprise and bugs for many people. (Python 2's division was modeled after C, which is still problematic, but at least C's division behavior is lexically determined by its static typing system, so it's usually somewhat less surprising. However, it would have been more clear if C had based its decision on the type being *assigned* to.)
With Python 3's implementation, it's always explicitly clear which kind of math you're doing. If your problem's math system depends on the types of the operands and you need to do type checking, then so be it. At least it's clear what's going on.
If it were just KB, that would only be somewhat annoying and confusing, like US vs imperial pints.
But when you introduce binary MB and GB they all have to be mixed, and it becomes absolutely infuriating. It makes doing the math to figure out how much stuff will fit on a drive almost as hard as using Roman numerals.
You're basically changing the radix of your numbers depending on their magnitude, for no good reason. (Disk drives have never had any capacity factor physically based on any power of two.) That's just stupid.
I can't fathom why some people get so angry because they think that drive manufacturers are trying to cheat them out of a couple of percent capacity, when it's been common knowledge for decades. But for some reason these same people don't mind having to break out a calculator to help them do what would often otherwise be trivial mental arithmetic.
unless you are seriously going to rewind the clock to 1970 and only allow distribution and playback of analog, concrete media,
I fondly remember my collection of concrete records. They had a uniquely gravelly sound that can't be duplicated by any digital technology. Sadly, I eventually got rid of them all because they were just too damned heavy to lug around.
Make all the apples-to-monster-trucks comparisons you want
And you can make all the false choice assertions you want. It doesn't mean that we can't work to pull ourselves out of the dark ages and stop burning dirt and spewing its byproducts into the air.
if you, personally, aren't limiting your own electricity use, not only are you not serious about the environment, you don't have a leg to stand on when it comes to telling other people how they should be getting their power.
I have been limiting my use. So it looks like I'm justified in telling you that you ought to be working towards getting a better source of power, not just spouting off about the status quo being inevitable.
On the bright side, my math indicates that 8e13 paper chads would take up about 20 thousand cubic meters of space. That would probably be enough free fuel to heat your home for a lifetime.
Just think how much you could save for yourself if you could keep 67% of your Federal income tax - and all your SSI/FICA payments - over the course of working 35-40 years... And that savings would survive to your estate/inheritors, not just disappear like SSI does, once you die.
Only if one of the financial crises that happens every couple of decades doesn't wipe you out.
The main problems are: A: Most people don't save money without being forced. B: Most people don't know how to invest. C: Even if you know how to invest, you can still lose your shirt. D: Irrespective of the above intractable problems, saving money and investments means nothing more than shifting bit patterns on some hard drives. It doesn't in any way solve the problem of supporting an millions of idle and ailing retirees over ever-expanding lifetimes. Any saved "assets" will get devalued in the markets to reflect that reality.
So your scenario does not do anything at all to address the problem of what to do with retirees in the real world, other than let a good fraction of them die in a gutter.
If the government is going to force me to spend money, I'd just as soon have them handle it directly, instead of making me hand it over to be skimmed by profiteering middlemen. (Who will probably eventually need to be bailed out with taxpayer money anyway).
For retirement, the government has a needed roll in setting standards for "safety net" investment choices, and in insuring people actually do save, but they don't need to handle the money.
Yeah, that would be better handled by outfits like AIG and Lehman Brothers.
Charity is great, and we should all be compassionate, and again the government has a needed role in setting standards, but they don't need to handle the money.
Just imagine how much junk mail it would take to raise enough charity funds to replace every government assistance program. The USPS would be profitable again after only a few days!
Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
By adding extra useless variables, as I originally pointed out. And introducing a sea of "&&"s. I guess at least it looks more like a bowl of pretzels than a dish of spaghetti.
Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
In a language like C++, unless there's a "try" block within the function, they are exactly the same as a "return" as far as that function is concerned, and can be invoked from the same places. I don't see why you think that that's acceptable if return isn't.
If you look at the FAQs for the Go language, the designers explain why they think exceptions suck in general, and why they largely replaced them with multiple return values. So not everyone shares your enthusiasm for exceptions, which are really just a kind of "return" statement on steroids.
1. "nested brackets" (blocks) are by definition not spaghetti.
I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.
Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if.... return statements. If you put each case in a function you still have the following problems: - If you do it the obvious way, you still need a deeply nested if-then chain. You haven't solved the problem. - If you put each check within a function and daisy-chain them, you get creepy action-at-a-distance. It's not clear to the reader that you made a whole bunch of functions that should only be called from one place, and that they must be daisy chained.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox), then plenty of people would argue with it in 2014.
The main problem with early exits is using them in C. But C is such an unsafe language in general, that's really the least of your worries. Other languages provide nice features like automatic destructors and "with" statements that make early exits perfectly reasonable.
Yeah, force people to write a big pile of nested bracket spaghetti and manually back their way out of every case. Make them introduce a bunch of otherwise useless flag variables and extra conditional statements to keep track of it all.
The best part of it all: When all that extra obfuscation causes bugs, it would be harder to pin the root cause on a simplistic generalization like "goto === bad".
Bucket sort to keep each individual stack small enough for the following insertion sort.
I think that's what people generally do: Bucket sort anything more than a couple dozen items, and insertion sort anything less.
I've tried various other sorting algorithms on decks of cards just for educational purposes. I've found them to be mostly very hard for humans to perform. I think that's probably because what's usually kept in a computer's stack is not evident in the layout of items, so all that info must be juggled in your head. I think that I remember heapsort being especially hard to keep track of, and that quicksort was no picnic, either.
Ah, the old "there aren't as many of you, so you're less important" argument.
No, they must be *more* important if they deserve using 100X more resources per person than the rest of us. That makes most of us less important than them. That's racist, sexist and bigoted and not politically correct.
I'm talking about 150-page user manuals that get fattened into 450-page volumes. If they're really giving you 1500-page telephone books with your electronic gadgets, then I pity you. A more efficient solution would be to target the packaging to the appropriate audience.
Another difference is that this is presumably for the benefit of just the ~3 million people in Quebec who don't know English. I suspect that the trilingual manuals have something to do with the NAFTA treaty between the US, Canada and Mexico, which covers more than 450 million people. So the 50% bloat is added for the benefit of well under 1% of the potential users.
Slashdot Mirror
Why can't we just be in insert mode constantly and use Ctrl+something for all the commands? Also use Shift+arrows to select text?
If you have any issues with RSI, then vim is by far the best editor (especially the GUI mode version).
The command mode allows you to formulate in your mind what you want to do, and accomplish it in the minimum possible key strokes. This is important because your brain won't wear out like your joints and tendons can. The command mode usually allows you to specify repeat counts to avoid repeatedly mashing keys. It lets you make common text selections such as words, nested brackets, statements, etc with a couple of key strokes. It also allows you to create macros on the fly and repeat previous commands further cut down on repetition.
I find that reaching for the arrow keys puts my wrists at an awkward angle which induces more stress. Having to pound on them repeatedly while holding down various combinations of control keys makes things worse. (To address a common complaint with vim, I've added a mapping of Alt+F to ESC, so I don't have to reach up for that key if I don't want to.)
I probably spend more time in command mode than insert mode when I'm using vim to write code. That says to me that keeping an editor always stuck in insert mode may not be the best idea.
I tried your scenario.
If play your boss and I exit with ':q', no problem. Your version is still there.
If I exit with ':wq', vim says: "E45: 'readonly' option is set (add ! to override)"
If I exit with ':wq!', vim says: "WARNING: The file has been changed since reading it!!!
Do you really want to write to it (y/n)?"
So I conclude that one of the following is likely the case:
a) your boss is was an idiot who would ignore a message ending with three exclamation points
b) you boss installed a bizarre custom vim config file that somehow allowed silent overwrites of modified files from readonly mode
c) your story is a fabricated troll
You use an H1B when you want the best guy, not when you want some low-cost faceless drone.
So now you get the "best guy" for the cost of a faceless drone plus some nominal administrative overhead. That's still much cheaper than having to get a "best guy" by a more conventional route, such as enticing the top staff of your competitors to come work for you with higher pay.
Moreover, you focus on a single case. However, in aggregate, there is no doubt that increasing the supply of workers for a particular field will lower the average salary paid for everyone. So companies can hire everyone at lower salaries.
Personally, if I have to divide up five children between two parents, I don't consider 2.5 to be an acceptable answer.
Acceptable to you or not, that's how it would be done physically.
Your acceptable solution involves a discrete math system. That's fine, but the safety of those children still shouldn't magically depend on whether you allocated them as Python ints or floats.
In the real world, 5 / 2 == 2.5. This is true whether the operands are integers or floats.
In some discrete math systems, 5 / 2 == 2.
A language has no way to really know what kind of problem you are working on and which calculation would be more appropriate. Python 2 made the assumption that if you fed in two integers, then you were working in a discrete math system. This turns out to not usually be the case, and was a source of surprise and bugs for many people. (Python 2's division was modeled after C, which is still problematic, but at least C's division behavior is lexically determined by its static typing system, so it's usually somewhat less surprising. However, it would have been more clear if C had based its decision on the type being *assigned* to.)
With Python 3's implementation, it's always explicitly clear which kind of math you're doing. If your problem's math system depends on the types of the operands and you need to do type checking, then so be it. At least it's clear what's going on.
WTF is wrong with KB meaning 1024 bytes?
If it were just KB, that would only be somewhat annoying and confusing, like US vs imperial pints.
But when you introduce binary MB and GB they all have to be mixed, and it becomes absolutely infuriating. It makes doing the math to figure out how much stuff will fit on a drive almost as hard as using Roman numerals.
You're basically changing the radix of your numbers depending on their magnitude, for no good reason. (Disk drives have never had any capacity factor physically based on any power of two.) That's just stupid.
I can't fathom why some people get so angry because they think that drive manufacturers are trying to cheat them out of a couple of percent capacity, when it's been common knowledge for decades. But for some reason these same people don't mind having to break out a calculator to help them do what would often otherwise be trivial mental arithmetic.
Some of us remember when storage manufacturers still used the correct definition of kilobytes and megabytes. It has been a while though.
Do you mean floppy disk manufacturers, who thought that a megabyte = 1000*1024?
unless you are seriously going to rewind the clock to 1970 and only allow distribution and playback of analog, concrete media,
I fondly remember my collection of concrete records. They had a uniquely gravelly sound that can't be duplicated by any digital technology. Sadly, I eventually got rid of them all because they were just too damned heavy to lug around.
Please keep reading past just the first five words of my original post and then try again.
A. Probably not. I'll bet that cave men burned coal or bitumen when they could find it.
B. Hydro power is not "green" at all. Most dams are small ecological disasters.
I said grubbing it and burning it.
If you were trying to make any kind of demonstration of reading comprehension, that wasn't it.
Make all the apples-to-monster-trucks comparisons you want
And you can make all the false choice assertions you want. It doesn't mean that we can't work to pull ourselves out of the dark ages and stop burning dirt and spewing its byproducts into the air.
if you, personally, aren't limiting your own electricity use, not only are you not serious about the environment, you don't have a leg to stand on when it comes to telling other people how they should be getting their power.
I have been limiting my use. So it looks like I'm justified in telling you that you ought to be working towards getting a better source of power, not just spouting off about the status quo being inevitable.
If you want to volunteer to go back to the dark ages yourself, go right ahead.
Grubbing dirt out of the ground and burning it is a "dark ages" thing.
On the bright side, my math indicates that 8e13 paper chads would take up about 20 thousand cubic meters of space. That would probably be enough free fuel to heat your home for a lifetime.
Neither, 8" floppies would be the way to go.
Hard sectored or soft sectored?
It would be best to decide up front before putting in the order for 80 million disks.
Just think how much you could save for yourself if you could keep 67% of your Federal income tax - and all your SSI/FICA payments - over the course of working 35-40 years... And that savings would survive to your estate/inheritors, not just disappear like SSI does, once you die.
Only if one of the financial crises that happens every couple of decades doesn't wipe you out.
The main problems are:
A: Most people don't save money without being forced.
B: Most people don't know how to invest.
C: Even if you know how to invest, you can still lose your shirt.
D: Irrespective of the above intractable problems, saving money and investments means nothing more than shifting bit patterns on some hard drives. It doesn't in any way solve the problem of supporting an millions of idle and ailing retirees over ever-expanding lifetimes. Any saved "assets" will get devalued in the markets to reflect that reality.
So your scenario does not do anything at all to address the problem of what to do with retirees in the real world, other than let a good fraction of them die in a gutter.
If the government is going to force me to spend money, I'd just as soon have them handle it directly, instead of making me hand it over to be skimmed by profiteering middlemen. (Who will probably eventually need to be bailed out with taxpayer money anyway).
See: Obamacare.
For retirement, the government has a needed roll in setting standards for "safety net" investment choices, and in insuring people actually do save, but they don't need to handle the money.
Yeah, that would be better handled by outfits like AIG and Lehman Brothers.
Charity is great, and we should all be compassionate, and again the government has a needed role in setting standards, but they don't need to handle the money.
Just imagine how much junk mail it would take to raise enough charity funds to replace every government assistance program. The USPS would be profitable again after only a few days!
Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
By adding extra useless variables, as I originally pointed out. And introducing a sea of "&&"s. I guess at least it looks more like a bowl of pretzels than a dish of spaghetti.
Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
In a language like C++, unless there's a "try" block within the function, they are exactly the same as a "return" as far as that function is concerned, and can be invoked from the same places. I don't see why you think that that's acceptable if return isn't.
If you look at the FAQs for the Go language, the designers explain why they think exceptions suck in general, and why they largely replaced them with multiple return values. So not everyone shares your enthusiasm for exceptions, which are really just a kind of "return" statement on steroids.
Then explain the lack of similar quantities of malware for iOS between 2007 and 2012?
It's for the same reason that the murder rate inside Disney World is very low.
1. "nested brackets" (blocks) are by definition not spaghetti.
I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.
Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if .... return statements. If you put each case in a function you still have the following problems:
- If you do it the obvious way, you still need a deeply nested if-then chain. You haven't solved the problem.
- If you put each check within a function and daisy-chain them, you get creepy action-at-a-distance. It's not clear to the reader that you made a whole bunch of functions that should only be called from one place, and that they must be daisy chained.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox), then plenty of people would argue with it in 2014.
The main problem with early exits is using them in C. But C is such an unsafe language in general, that's really the least of your worries. Other languages provide nice features like automatic destructors and "with" statements that make early exits perfectly reasonable.
Yeah, force people to write a big pile of nested bracket spaghetti and manually back their way out of every case. Make them introduce a bunch of otherwise useless flag variables and extra conditional statements to keep track of it all.
The best part of it all: When all that extra obfuscation causes bugs, it would be harder to pin the root cause on a simplistic generalization like "goto === bad".
Bucket sort to keep each individual stack small enough for the following insertion sort.
I think that's what people generally do: Bucket sort anything more than a couple dozen items, and insertion sort anything less.
I've tried various other sorting algorithms on decks of cards just for educational purposes. I've found them to be mostly very hard for humans to perform. I think that's probably because what's usually kept in a computer's stack is not evident in the layout of items, so all that info must be juggled in your head. I think that I remember heapsort being especially hard to keep track of, and that quicksort was no picnic, either.
Ah, the old "there aren't as many of you, so you're less important" argument.
No, they must be *more* important if they deserve using 100X more resources per person than the rest of us. That makes most of us less important than them. That's racist, sexist and bigoted and not politically correct.
I'm talking about 150-page user manuals that get fattened into 450-page volumes. If they're really giving you 1500-page telephone books with your electronic gadgets, then I pity you. A more efficient solution would be to target the packaging to the appropriate audience.
Another difference is that this is presumably for the benefit of just the ~3 million people in Quebec who don't know English. I suspect that the trilingual manuals have something to do with the NAFTA treaty between the US, Canada and Mexico, which covers more than 450 million people. So the 50% bloat is added for the benefit of well under 1% of the potential users.