Automation may improve productivity, but what is productivity? It's been calculated that Chinese peasants in the Han Dynasty worked an average 13 hour week, and medieval European peasants didn't work much more. Now, OK, they didn't have access to decent healthcare, and because of poor transport they were vulnerable to poor local weather causing famine from time to time. And, of course, they didn't have MTV or Facebook or even iPads. But on the whole they were much better fed (on much better food) than you are now. If you could have a simple life with a comfortable home for thirteen hours a week, would you? I know I would.
I'm not against automation. Automation means that we can get back to working thirteen hours a week, without having to give up MTV and Facebook and iPads, or even modern healthcare. But we can only do that if the surplus value created by automation is widely shared, rather than being captured by elites.
That's a really bad analogy. Peering at someone's credit card - even if it is under a napkin - is quite obviously very bad manners indeed. If you're saying unauthorised penetration testing is like peering at someone's credit card, then it's clearly wrong.
And speaking as someone who has his own little toy server out in the cloud, I'd very much prefer to do my own damn penetration testing, thank you.
Dead reckoning - navigation where you have no accurate fix - has been around for literally hundreds of years, and it is spelled 'dead reckoning' - because it's reckoning (of position) without a live fix. When I learned to navigate small boats fifty years ago, it was still pretty standard - because sun sights are awkward, and in any case using sun sights alone you can't get two position lines at the same time, so you have to do a running fix (which involves some dead reckoning). Even in coastal navigation you can't always get bearings on two good landmarks at the same time.
If you were thinking you would realise that drone strikes on a civilian population - on women, on children, on funerals, on weddings - recruit a thousand terrorists for every one they kill. Of course the CIA and the military promote this policy. More terrorists means more money for the CIA and the military, terrorism and counter-terrorism are inherently symbiotic. But foreign policy should not be dictated by the needs of inter-agency pissing matches in Washington DC.
I have never, ever bought an Apple product of any kind, but considering build quality the MacBook Air is probably better value for money than the very similar Asus Ultrabook which I do have.
I suspect because the part of their system which changes passwords is seriously overloaded. I'm trying to change mine, but so far can't even get the page to load.
The whole purpose of these treaties are to carve out new opportunities for special interests and rent seekers to harvest wealth from the small folk like you and me. Whatever you think of the benefits of free trade, these treaties are created to prevent it, and for no other reason.
I used these things. They really existed. And they made modern IDEs like Eclipse and IntelliJ and Netbeans and Visual Studio look really crude and primitive. The Lisp machines were horrendously expensive, though. The last one that the nice Government bought me cost £25,000 at a time when a Sun workstation cost £4,000. And so we really have forgotten what was possible.
However, the machines we have now are enormously more powerful than the machines we had then. My Xerox 1186 in 1987 had (I think) 8Mb of real RAM and about 80Mb of disk, and ran at two MIPS. My desktop machine at home has 16Gb of RAM and runs at 18,000 MIPS. We really could begin to run the big software development environments of the 'golden age' again, on machines everyone can afford. Clojure and LightTable are a real step in the right generation; but they're still a long way behind where we were thirty years ago.
InterLisp (and a number of other things coming out of Xerox PARC in the early eighties) had the same feature. You saved the running state of your system to file, you invoked the function (sysout). To restore the running state of your system from a file, you invoked (sysin filename). Essentially this was a memory dump of the heap, but it had the special property that the 'spaghetti stack' - the branching stack structure through which InterLisp managed multitasking - was implemented in the heap rather than as a separate structure, so loading in the heap also loaded in the stack, for all threads.
Obviously, in InterLisp as in Smalltalk, everything in memory was inspectable and editable, and when you edited a function that didn't mean editing and reloading a file, the source code was an in-memory structure. It wasn't entirely without problems - there were small semantic differences between interpreted code and compiled code (if I remember correctly interpreted code implemented shallow binding while compiled code implemented deep binding), so that when you compiled your code its behaviour could change. Also it was possible, if you added a comment in the wrong place, that it could change the semantics of a function. For example if you added a comment as the last form in a function body, that function would always return nil. Nevertheless in terms of programmer productivity these environments were streets ahead of anything that's commercially available now; and although I love LightTable and hope that it is the shape of things to come, even LightTable isn't a patch on InterLisp's DEdit.
A small minority of companies, with very special needs, are using NoSql databases for a small proportion of their operations. Those companies do include some big ones, such as Google and Twitter, but still in absolute terms the numbers are small. A tiny minority of companies have moved away from relational databases altogether. But the numbers are statistically insignificant and are likely to remain so for decades. And the relational model does have some real and enduring benefits which will make it the right tool for many jobs far into the future.
Remember this is an industry that advances very slowly indeed. Your bank, and your utility companies, are still using programs written in COBOL - technology which is fifty years behind the curve.
Not if you're even considering this legislation, you're not. Your state may not be corrupted by the commercial sector, but it is surely corrupted by the security sector. Not all corruption is financial.
OK, so a pedal bicycle is a very low powered road vehicle, but the same equation applies. To achieve a better power to weight ratio, you can either increase power or decrease weight - and decreased weight has the added bonus of lower loads on suspension and tyres in fast corners.
If we continue burning coal at this rate, human life as we know it won't see 2100. Civilisation? Well, probably cockroaches will one day develop civilisation.
Actually, this is untrue. The world has never faced a technology which had the potential to take out the entire human ecosystem before. Fossil fuels certainly will become obsolete sooner or later - when 90% of the human population has died of starvation, they'll be obsolete. But it would be a much better thing if we could stop using them before we'd destroyed the atmospheric and ocean systems which we depend on for our survival.
OK, so, I'm a hero warrior with a really big battle axe. There's a flimsy door with a little lock on it...
Yes, locked doors can be useful and interesting parts of game puzzles, but make it believable, please! If your first person character is big, strong and well equipped, and you want to make it credible that he can't get through a door, the door also needs to be big, strong and well equipped.
The often repeated mantra that high level language compilers do a better job than humans isn't true, and doesn't become true through repetition. The compilers can do no better than the person programming them, and for a finite size compiler, the optimizations are generic, not specific. And a good low level programmer can take knowledge into effect that the compiler doesn't have.
Two things. Programmers are expensive, silicon is cheap. And really good low-level programmers (which I am not and don't claim to be) are (and deserve to be) very expensive indeed.
When you're writing a bit of code which is going to run on hundreds of thousands of processors all over the world (as OpenSSL is), the cost/benefit does move in low-level programmings favour. If you save just a few cycles on each of billions of operations on millions of processors, it's worth throwing resource at that optimisation. But OpenSSL (like the Linux kernel) is a special case. Most perfectly ordinary good programmers will write more cost-effective code using languages which don't require them (for example) to keep track of memory assignment.
Also, most human beings can't hold an effective map in their minds of the operating states of a moderately complex program. And people make mistakes - even the best of us.Software, by contrast, is very good at detail, repetitious, complex tasks like keeping track of what bit of memory has been assigned for what purpose, and noticing when nothing remaining in the system holds a pointer to that data. There are whole classes of programming error which good compilers will simply never make.
I was doing a post-accident audit on safety-critical (closed source) code a few years ago. The reason for the failure was that someone had used strcat to concatenate strings for an error message, where the strings being concatenated were stored in the data segment (yes, think about it for a moment). It cost millions of pounds worth of damage, and it was very lucky no-one died. If the software concerned had been written in (for example) Java, the accident wouldn't have happened. Yet the software had been written by a very senior C++ programmer, and had gone through four separate code reviews before being accepted into service - and all four had missed it.
Since it's intended for space walks, why the ${IMPRECATION} does it needs legs?
I was going to say 'why on Earth', but that's kind of the point. It's not going to be on Earth. It's going to be in zero-gravity, where legs are completely useless.
Similar with a phone. If it were made somewhat modular where RAM, flash storage, and other parts were upgradable, with the antenna being easily swapped out, then paying twice as much for the device wouldn't be a bad thing.
Given that the US is (as you correctly point out) among the most profligate and inefficient economies in the world, setting the tax so that it didn't affect the US would mean setting it so that it didn't affect anyone anywhere. which would be entirely pointless.
Cut tree down, cut tree up, stack it in a shed for two years to dry, burn it, spread the resultant ash on the garden. That's processing, I suppose, And there's labour involved, which you might consider costly. But you don't need caustic chemicals, and the only high temperatures involved go to heating your house, which is what fuel is all about.
Why not go out and invent something actually useful?
Slashdot Mirror
Since Qt works with Objective-C and Objective-C works with Swift, doesn't Qt already (automatically) work with Swift?
Automation may improve productivity, but what is productivity? It's been calculated that Chinese peasants in the Han Dynasty worked an average 13 hour week, and medieval European peasants didn't work much more. Now, OK, they didn't have access to decent healthcare, and because of poor transport they were vulnerable to poor local weather causing famine from time to time. And, of course, they didn't have MTV or Facebook or even iPads. But on the whole they were much better fed (on much better food) than you are now. If you could have a simple life with a comfortable home for thirteen hours a week, would you? I know I would.
I'm not against automation. Automation means that we can get back to working thirteen hours a week, without having to give up MTV and Facebook and iPads, or even modern healthcare. But we can only do that if the surplus value created by automation is widely shared, rather than being captured by elites.
That's a really bad analogy. Peering at someone's credit card - even if it is under a napkin - is quite obviously very bad manners indeed. If you're saying unauthorised penetration testing is like peering at someone's credit card, then it's clearly wrong.
And speaking as someone who has his own little toy server out in the cloud, I'd very much prefer to do my own damn penetration testing, thank you.
Dead reckoning - navigation where you have no accurate fix - has been around for literally hundreds of years, and it is spelled 'dead reckoning' - because it's reckoning (of position) without a live fix. When I learned to navigate small boats fifty years ago, it was still pretty standard - because sun sights are awkward, and in any case using sun sights alone you can't get two position lines at the same time, so you have to do a running fix (which involves some dead reckoning). Even in coastal navigation you can't always get bearings on two good landmarks at the same time.
You're not thinking at all, you're just emoting.
If you were thinking you would realise that drone strikes on a civilian population - on women, on children, on funerals, on weddings - recruit a thousand terrorists for every one they kill. Of course the CIA and the military promote this policy. More terrorists means more money for the CIA and the military, terrorism and counter-terrorism are inherently symbiotic. But foreign policy should not be dictated by the needs of inter-agency pissing matches in Washington DC.
I have never, ever bought an Apple product of any kind, but considering build quality the MacBook Air is probably better value for money than the very similar Asus Ultrabook which I do have.
I suspect because the part of their system which changes passwords is seriously overloaded. I'm trying to change mine, but so far can't even get the page to load.
In the modern world, only those who are harmful to society are financially successful. Sad, but true.
The whole purpose of these treaties are to carve out new opportunities for special interests and rent seekers to harvest wealth from the small folk like you and me. Whatever you think of the benefits of free trade, these treaties are created to prevent it, and for no other reason.
I used these things. They really existed. And they made modern IDEs like Eclipse and IntelliJ and Netbeans and Visual Studio look really crude and primitive. The Lisp machines were horrendously expensive, though. The last one that the nice Government bought me cost £25,000 at a time when a Sun workstation cost £4,000. And so we really have forgotten what was possible.
However, the machines we have now are enormously more powerful than the machines we had then. My Xerox 1186 in 1987 had (I think) 8Mb of real RAM and about 80Mb of disk, and ran at two MIPS. My desktop machine at home has 16Gb of RAM and runs at 18,000 MIPS. We really could begin to run the big software development environments of the 'golden age' again, on machines everyone can afford. Clojure and LightTable are a real step in the right generation; but they're still a long way behind where we were thirty years ago.
InterLisp (and a number of other things coming out of Xerox PARC in the early eighties) had the same feature. You saved the running state of your system to file, you invoked the function (sysout). To restore the running state of your system from a file, you invoked (sysin filename). Essentially this was a memory dump of the heap, but it had the special property that the 'spaghetti stack' - the branching stack structure through which InterLisp managed multitasking - was implemented in the heap rather than as a separate structure, so loading in the heap also loaded in the stack, for all threads.
Obviously, in InterLisp as in Smalltalk, everything in memory was inspectable and editable, and when you edited a function that didn't mean editing and reloading a file, the source code was an in-memory structure. It wasn't entirely without problems - there were small semantic differences between interpreted code and compiled code (if I remember correctly interpreted code implemented shallow binding while compiled code implemented deep binding), so that when you compiled your code its behaviour could change. Also it was possible, if you added a comment in the wrong place, that it could change the semantics of a function. For example if you added a comment as the last form in a function body, that function would always return nil. Nevertheless in terms of programmer productivity these environments were streets ahead of anything that's commercially available now; and although I love LightTable and hope that it is the shape of things to come, even LightTable isn't a patch on InterLisp's DEdit.
A small minority of companies, with very special needs, are using NoSql databases for a small proportion of their operations. Those companies do include some big ones, such as Google and Twitter, but still in absolute terms the numbers are small. A tiny minority of companies have moved away from relational databases altogether. But the numbers are statistically insignificant and are likely to remain so for decades. And the relational model does have some real and enduring benefits which will make it the right tool for many jobs far into the future.
Remember this is an industry that advances very slowly indeed. Your bank, and your utility companies, are still using programs written in COBOL - technology which is fifty years behind the curve.
RTFA! It's not used for storing manuals.
Not if you're even considering this legislation, you're not. Your state may not be corrupted by the commercial sector, but it is surely corrupted by the security sector. Not all corruption is financial.
OK, so a pedal bicycle is a very low powered road vehicle, but the same equation applies. To achieve a better power to weight ratio, you can either increase power or decrease weight - and decreased weight has the added bonus of lower loads on suspension and tyres in fast corners.
... that stocks have any intrinsic value?
If we continue burning coal at this rate, human life as we know it won't see 2100. Civilisation? Well, probably cockroaches will one day develop civilisation.
Actually, this is untrue. The world has never faced a technology which had the potential to take out the entire human ecosystem before. Fossil fuels certainly will become obsolete sooner or later - when 90% of the human population has died of starvation, they'll be obsolete. But it would be a much better thing if we could stop using them before we'd destroyed the atmospheric and ocean systems which we depend on for our survival.
OK, so, I'm a hero warrior with a really big battle axe. There's a flimsy door with a little lock on it...
Yes, locked doors can be useful and interesting parts of game puzzles, but make it believable, please! If your first person character is big, strong and well equipped, and you want to make it credible that he can't get through a door, the door also needs to be big, strong and well equipped.
The often repeated mantra that high level language compilers do a better job than humans isn't true, and doesn't become true through repetition. The compilers can do no better than the person programming them, and for a finite size compiler, the optimizations are generic, not specific. And a good low level programmer can take knowledge into effect that the compiler doesn't have.
Two things. Programmers are expensive, silicon is cheap. And really good low-level programmers (which I am not and don't claim to be) are (and deserve to be) very expensive indeed.
When you're writing a bit of code which is going to run on hundreds of thousands of processors all over the world (as OpenSSL is), the cost/benefit does move in low-level programmings favour. If you save just a few cycles on each of billions of operations on millions of processors, it's worth throwing resource at that optimisation. But OpenSSL (like the Linux kernel) is a special case. Most perfectly ordinary good programmers will write more cost-effective code using languages which don't require them (for example) to keep track of memory assignment.
Also, most human beings can't hold an effective map in their minds of the operating states of a moderately complex program. And people make mistakes - even the best of us.Software, by contrast, is very good at detail, repetitious, complex tasks like keeping track of what bit of memory has been assigned for what purpose, and noticing when nothing remaining in the system holds a pointer to that data. There are whole classes of programming error which good compilers will simply never make.
I was doing a post-accident audit on safety-critical (closed source) code a few years ago. The reason for the failure was that someone had used strcat to concatenate strings for an error message, where the strings being concatenated were stored in the data segment (yes, think about it for a moment). It cost millions of pounds worth of damage, and it was very lucky no-one died. If the software concerned had been written in (for example) Java, the accident wouldn't have happened. Yet the software had been written by a very senior C++ programmer, and had gone through four separate code reviews before being accepted into service - and all four had missed it.
Since it's intended for space walks, why the ${IMPRECATION} does it needs legs?
I was going to say 'why on Earth', but that's kind of the point. It's not going to be on Earth. It's going to be in zero-gravity, where legs are completely useless.
Similar with a phone. If it were made somewhat modular where RAM, flash storage, and other parts were upgradable, with the antenna being easily swapped out, then paying twice as much for the device wouldn't be a bad thing.
What, like this, you mean?
Given that the US is (as you correctly point out) among the most profligate and inefficient economies in the world, setting the tax so that it didn't affect the US would mean setting it so that it didn't affect anyone anywhere. which would be entirely pointless.
The babylonians and God's favourite people thought that pi=3. Hey, it's good enough for government work, and probably for fighting zombies.
Cut tree down, cut tree up, stack it in a shed for two years to dry, burn it, spread the resultant ash on the garden. That's processing, I suppose, And there's labour involved, which you might consider costly. But you don't need caustic chemicals, and the only high temperatures involved go to heating your house, which is what fuel is all about.
Why not go out and invent something actually useful?