In a resource shortage, yes, the very wealthy can always get what they want.
Sorry, I meant to reply to this. That point is somewhat irrelevant. The unfairness I'm talking about isn't that the rich are privileged. To be sure, it's distasteful, but not a fatal flaw on its own. The fatal flaw is that in a resource shortage, the very poor never get anything (in a free market economy). A fair system has to ensure that all the participants regularly get access to everything that's being traded.
Your example illustrates this perfectly. You forego access to a new 2TB drive, which leads you to change your behaviour, while a company with more money to spend on hardware isn't inconvenienced in the same way. But you implicitly accept that because you have faith that the prices will come down, and your projects are merely deferred in time. You expect to get something you want eventually, so you feel this is fair.
Another funny thing about markets
is how they invariably get replaced by rationing when the survival of
a nation is at stake. When the German U-boat blockade of England in World War
II prevented supplies coming in, the lowly, suboptimal, rationing
method was more reliable and fair than free markets (Incidentally , it also prevented
rioting and a civil war. What do you think would have happened if half
a million of the poorest British subjects suddenly were unable to buy
any food *at all*?)
There are plenty of alternative ways to allocate resources.
For example, there's the round robin method. Put 100 people in a queue. The person at the front gets served and must go to the back of the queue afterwards. So the first time there's a shortage, people #1 to #50 get the drives. The second time there's a shortage, people #51 to #100 get the drives.
Another method is to pick 50 people out of 100 randomly and let them have the available drives. This doesn't require to implement a queue, but has a small chance of overlap in repeated allocations.
The point here is that fairness requires that all individuals are served equal amounts over their lifetimes, which can't happen in a market as the OP showed.
If you think about it, this problem also shows up in all modern operating systems. There are limited resources like CPU, memory, disk, etc, and the process scheduler has to decide how much time to give to each running process. How do they do it? They certainly don't use markets. What if they did? You'd have "rich" processes that hog all the CPU time, and you'd have "poor" processes that couldn't get any CPU time at all. It would be a crazy fun Linux kernel patch, though:)
That's not a new problem, is it? For example, the template qualifier is already necessary in template code when an expression like T.x(3) occurs. Does that refer to a template method x of class T invoked with the value 3, or is it a member variable T.x compared with the value of variable y, which is then compared with the integer 3?
Although come to think of it, that's pretty damn ugly too:(
In principle, all you need is to have a set of instructions that can
recreate all the machine code instructions in your PC. So that means I
think comparisons, jumps and reading/writing global values (a memory
location is a global variable, eg named byte000001, byte000002
etc). But your point is well made, without support for local variables
and stack frames you'd have to simulate all that as well. There's a
lot of layers.
Thanks for a great explanation. BTW, this is also exactly why markets
are fundamentally unfair and flawed systems. When there is a resource
shortage, the richest person can *always* get an item, and the poorest
person can *never* get an item. It's just a system of entitlement and
privilege based on numbers in a bank account.
One thing I think I don't like is return types after the function
definition. It seems too artificial, when they could have just
changed the scoping rules slightly and kept the return type before the
function prototype.
C++ has always been about performance and low level control. However, having
higher level constructs in addition is a good thing.
Take goto, which is all that's really needed for modern programming.
Using goto, you can implement subroutines (gosub like functions), while and for loops, etc. But each time you implement one of the higher constructs, your implementation will be slightly different. And if you force yourself to use the optimal implementation all the time, you'll just be writing a lot of boiler plate code. So having functions and while loops implemented as language constructs is a good thing. Similarly, std::thread + lambdas is a great addition.
SCENARIO 1. Being skeptical about one's own results is important. That's the best way of reducing wasted effort. With time and experience, researchers become aware that most ideas which seems brilliant at first are probably not. It's an important lesson to learn, as it gives perspective on time management. But it's no good publishing them. That leads to
1) information overload where the good stuff is hidden in a lot of mundane stuff, and there's only so much time a person can spend reading papers. As it is, the scientific literature is already too big for anyone to keep up to date on everything that could be relevant to their work.
2) human psychology is that if a researcher believes his idea is brilliant, he'll not be deterred by someone claiming the opposite. That other person could be wrong or sloppy or just missed a tiny detail that makes all the difference.
And anyway, if you don't believe deep down that you are capable of solving things that others failed at, then you'll have a difficult time being a researcher.
SCENARIO 2 That's not an example of publishing negative results. It's publishing a positive, which turns out to be flawed or wrong. Publishing a negative result is when you say "well, I tried to do something, but I didn't succeed", whereas a positive result is "well, I did this, which gets us 10% of the way to something really hard to do"
Negative results shouldn't be published. But they can be good advice to put in textbooks or to talk about with colleagues. Of course that doesn't count as a publication in the same way.
I know. Personally, I don't particularly like that aspect because it
breaks the mental mapping between editing frames and tasks. I also
like the fact that independent processes are more crash proof.
BTW, 2-3 seconds seems a little slow to load. If you start with a plain vanilla invocation, it should load instantly:
emacs -nw --no-site-file -q ;
The graphical version (emacs -Q) does something similar. X resources introduce a small delay, that can be optimized by doing the equivalent setup in elisp.
There's a perfectly rational explanation for my madness:)
One of the things that infuriates people who like GUIs is when
Cut'n'Paste doesn't work properly in some applications. Even when it
works, the data transfers through cut and paste depend a lot on what
an application will recognize or let you copy. E.g. you might copy an
image from the web browser and yet you can't insert it as a background for
your music player.
I'm the same way with editing text. Nearly every application requires
some text input somewhere, and the ways the native text fields work are
slightly (or a lot) different in each application. By using Emacs
everywhere possible, I can have a uniform editing experience that improves the overall
UI a lot. I can spell check a slashdot post without needing a special
module in my browser or my MUA, I can move forward/backward by single
characters, words, sentences, or paragraphs, I have automatic saving
in case of an application crash, load/save from external files,
syntax coloring which adapts to the content type
and macro capability in *all* the applications I regularly use, and
it all works the *same* way everywhere.
Internet connection was an `option' which is not anymore these days.
Heh. The other day, I helped a friend set up his new USB wireless modem on his laptop. When he plugged it in, the ISP's app loaded automatically but Windows 7 couldn't recognize the hardware, and brought up a window to search for a driver on the internet,...
For me, the most dramatic example of the progress of hardware in the intervening years is Emacs.
It used to be regarded as a heavyweight editing environment, comparable in scope and resource requirements to a full programmer's IDE. There was even a special server designed just to allow several editing windows (aka frames) to coexist.
Now, it's so lightweight and fast to load up, my web browser launches a completely independent Emacs for each comment field in a web page, my MUA launches its own Emacs for writing mails, I have multiple independent Emacs processes for editing code, and another for writing LaTeX.
When you talk about the end, do you mean the Alien bit? I don't see that having aliens in a movie is any worse than having a weapon of god, or a cult of evil magic, or yet another goblet with magical powers from god. All the movies have extranatural central elements.
What made the first movie so great was that there was a Quest with a satisfying ending. It also started with a mini-quest to set the scene. The other movies replaced some of the elements while keeping some others. The last one didn't really have a quest, it was more like a rescue mission, and it didn't have a mini-quest to begin with. Also the puzzles were quite weak, and without them it's just an action movie. But the Alien bit at the end I would classify as a pure Indiana Jones story element.
That's not what was implied in TFA. The implication was that the car was dead - you couldn't turn it on and drive it, unless you got it serviced, which involved some amount of rebooting.
If you don't publish, what prevents people from investing time in that less
effective scheduling algorithm again and again?
That's not how it works. People (ought to) compare their homebrew less effective algorithm with the best one that's published in the literature. They'll know by doing those comparisons to not waste time on suboptimal methods. There's really no need at all to publish a paper saying "I just invented method X and it is less effective than well known method Y".
Writting up negative results
is just as important as writing up positive one.
IMHO it's not.
In general, getting a positive result is hard, and advances Science.
Getting negative results can be hard in some cases, but there's nothing that
enforces difficulty, and the line into triviality is blurred.
So you find that doing X doesn't give Y. Well, doing X also doesn't give Z, or T, or U. There are millions of alternatives, all equally valid. By encouraging the publication of negative results, it becomes very difficult to ensure that worthwhile alternatives are explored. What makes Y more interesting than Z or T?
Because positive results actually solve problems, they remain hard and worthwhile over time. But while there have been spectacular examples of negative results in Science, if they became common, over time there would be a general devolution into triviality or irrelevance.
I don't know about you, but if the wall-paper for the new toilet is three seashells, I'll take my chances with being cryogenically frozen until December 31, 2999!
Slashdot Mirror
Sorry, I meant to reply to this. That point is somewhat irrelevant. The unfairness I'm talking about isn't that the rich are privileged. To be sure, it's distasteful, but not a fatal flaw on its own. The fatal flaw is that in a resource shortage, the very poor never get anything (in a free market economy). A fair system has to ensure that all the participants regularly get access to everything that's being traded.
Your example illustrates this perfectly. You forego access to a new 2TB drive, which leads you to change your behaviour, while a company with more money to spend on hardware isn't inconvenienced in the same way. But you implicitly accept that because you have faith that the prices will come down, and your projects are merely deferred in time. You expect to get something you want eventually, so you feel this is fair.
Another funny thing about markets is how they invariably get replaced by rationing when the survival of a nation is at stake. When the German U-boat blockade of England in World War II prevented supplies coming in, the lowly, suboptimal, rationing method was more reliable and fair than free markets (Incidentally , it also prevented rioting and a civil war. What do you think would have happened if half a million of the poorest British subjects suddenly were unable to buy any food *at all*?)
For example, there's the round robin method. Put 100 people in a queue. The person at the front gets served and must go to the back of the queue afterwards. So the first time there's a shortage, people #1 to #50 get the drives. The second time there's a shortage, people #51 to #100 get the drives.
Another method is to pick 50 people out of 100 randomly and let them have the available drives. This doesn't require to implement a queue, but has a small chance of overlap in repeated allocations.
The point here is that fairness requires that all individuals are served equal amounts over their lifetimes, which can't happen in a market as the OP showed.
If you think about it, this problem also shows up in all modern operating systems. There are limited resources like CPU, memory, disk, etc, and the process scheduler has to decide how much time to give to each running process. How do they do it? They certainly don't use markets. What if they did? You'd have "rich" processes that hog all the CPU time, and you'd have "poor" processes that couldn't get any CPU time at all. It would be a crazy fun Linux kernel patch, though :)
Although come to think of it, that's pretty damn ugly too :(
In principle, all you need is to have a set of instructions that can recreate all the machine code instructions in your PC. So that means I think comparisons, jumps and reading/writing global values (a memory location is a global variable, eg named byte000001, byte000002 etc). But your point is well made, without support for local variables and stack frames you'd have to simulate all that as well. There's a lot of layers.
Thanks for a great explanation. BTW, this is also exactly why markets are fundamentally unfair and flawed systems. When there is a resource shortage, the richest person can *always* get an item, and the poorest person can *never* get an item. It's just a system of entitlement and privilege based on numbers in a bank account.
What? Kelli McCarthy is a senator now? Do the other senators know where that American flag has been? ;-)
One thing I think I don't like is return types after the function definition. It seems too artificial, when they could have just changed the scoping rules slightly and kept the return type before the function prototype.
Take goto, which is all that's really needed for modern programming. Using goto, you can implement subroutines (gosub like functions), while and for loops, etc. But each time you implement one of the higher constructs, your implementation will be slightly different. And if you force yourself to use the optimal implementation all the time, you'll just be writing a lot of boiler plate code. So having functions and while loops implemented as language constructs is a good thing. Similarly, std::thread + lambdas is a great addition.
SCENARIO 1. Being skeptical about one's own results is important. That's the best way of reducing wasted effort. With time and experience, researchers become aware that most ideas which seems brilliant at first are probably not. It's an important lesson to learn, as it gives perspective on time management. But it's no good publishing them. That leads to
1) information overload where the good stuff is hidden in a lot of mundane stuff, and there's only so much time a person can spend reading papers. As it is, the scientific literature is already too big for anyone to keep up to date on everything that could be relevant to their work.
2) human psychology is that if a researcher believes his idea is brilliant, he'll not be deterred by someone claiming the opposite. That other person could be wrong or sloppy or just missed a tiny detail that makes all the difference. And anyway, if you don't believe deep down that you are capable of solving things that others failed at, then you'll have a difficult time being a researcher.
SCENARIO 2 That's not an example of publishing negative results. It's publishing a positive, which turns out to be flawed or wrong. Publishing a negative result is when you say "well, I tried to do something, but I didn't succeed", whereas a positive result is "well, I did this, which gets us 10% of the way to something really hard to do"
Negative results shouldn't be published. But they can be good advice to put in textbooks or to talk about with colleagues. Of course that doesn't count as a publication in the same way.
BTW, 2-3 seconds seems a little slow to load. If you start with a plain vanilla invocation, it should load instantly:
emacs -nw --no-site-file -q ;
The graphical version (emacs -Q) does something similar. X resources introduce a small delay, that can be optimized by doing the equivalent setup in elisp.
One of the things that infuriates people who like GUIs is when Cut'n'Paste doesn't work properly in some applications. Even when it works, the data transfers through cut and paste depend a lot on what an application will recognize or let you copy. E.g. you might copy an image from the web browser and yet you can't insert it as a background for your music player.
I'm the same way with editing text. Nearly every application requires some text input somewhere, and the ways the native text fields work are slightly (or a lot) different in each application. By using Emacs everywhere possible, I can have a uniform editing experience that improves the overall UI a lot. I can spell check a slashdot post without needing a special module in my browser or my MUA, I can move forward/backward by single characters, words, sentences, or paragraphs, I have automatic saving in case of an application crash, load/save from external files, syntax coloring which adapts to the content type and macro capability in *all* the applications I regularly use, and it all works the *same* way everywhere.
A nice one from that era I liked was Descent
Heh. The other day, I helped a friend set up his new USB wireless modem on his laptop. When he plugged it in, the ISP's app loaded automatically but Windows 7 couldn't recognize the hardware, and brought up a window to search for a driver on the internet, ...
It used to be regarded as a heavyweight editing environment, comparable in scope and resource requirements to a full programmer's IDE. There was even a special server designed just to allow several editing windows (aka frames) to coexist.
Now, it's so lightweight and fast to load up, my web browser launches a completely independent Emacs for each comment field in a web page, my MUA launches its own Emacs for writing mails, I have multiple independent Emacs processes for editing code, and another for writing LaTeX.
What made the first movie so great was that there was a Quest with a satisfying ending. It also started with a mini-quest to set the scene. The other movies replaced some of the elements while keeping some others. The last one didn't really have a quest, it was more like a rescue mission, and it didn't have a mini-quest to begin with. Also the puzzles were quite weak, and without them it's just an action movie. But the Alien bit at the end I would classify as a pure Indiana Jones story element.
That's not what was implied in TFA. The implication was that the car was dead - you couldn't turn it on and drive it, unless you got it serviced, which involved some amount of rebooting.
That's not how it works. People (ought to) compare their homebrew less effective algorithm with the best one that's published in the literature. They'll know by doing those comparisons to not waste time on suboptimal methods. There's really no need at all to publish a paper saying "I just invented method X and it is less effective than well known method Y".
IMHO it's not. In general, getting a positive result is hard, and advances Science. Getting negative results can be hard in some cases, but there's nothing that enforces difficulty, and the line into triviality is blurred.
So you find that doing X doesn't give Y. Well, doing X also doesn't give Z, or T, or U. There are millions of alternatives, all equally valid. By encouraging the publication of negative results, it becomes very difficult to ensure that worthwhile alternatives are explored. What makes Y more interesting than Z or T?
Because positive results actually solve problems, they remain hard and worthwhile over time. But while there have been spectacular examples of negative results in Science, if they became common, over time there would be a general devolution into triviality or irrelevance.
Because university administrators don't care about Science, they care about parking fees and paying for buildings and maintaining the greens.
... do we need to reboot cars now?
I don't know about you, but if the wall-paper for the new toilet is three seashells, I'll take my chances with being cryogenically frozen until December 31, 2999!
Chak-chak.
Taco got hitched, and she won't let him hang with the boys...
@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;
In C++, this would be something like
sort(lines.begin(), lines.end(), [](line_t *a, line_t *b) { return strcmp(a->name, b->name) < 0; });
@Files = <c:/Windows/*.exe>;
In C++, this is impossible as the concept of a filesystem with a directory structure isn't portable. But using Boost, you could do
for_each(directory_iterator("c:/Windows"), directory_iterator(), [&v](directory_entry e) { string s= e.path().native(); if( ends_with(s, ".exe") ) v.push_back(s); });
although maybe there's a simpler way.