There was another article last week pointing out that under both UK and EU law it is illegal to deprive people of their citizenship without due process. There's a legal challenge being mounted as a result. 17,410,742 people voted to leave the EU. The estimated UK population is 64,088,222, so that leaves 46,677,480 people who will be deprived of their EU citizenship without having either committed a crime for which removal of citizenship is a valid legal penalty or having explicitly disclaimed it. There's an interesting catch-22 if the challenge is upheld, because the UK can't remove EU citizenship from these people without repealing a load of laws, but it can't repeal those laws unless it first leaves the EU.
Part of the problem is that they overestimated the amount. Part of the problem is that they made the numbers seem scary (about £6/week/person seems a lot less scary given all of the things that we get in return and the actual amount is closer to £2/week.). The biggest part of the problem is that they claimed that we'd have that money back if the left, but also claimed that we'd retain access to the common market. All of the countries that have access to the common market but aren't members of the EU are paying, per capita, more than the UK after the rebate. If their bus had said 'we send the EU £350 million per week, let's pay more but have no say in how it's spent. Vote Leave.' then that would have been fine.
The most important thing is that they were saying that the UK Government would be free to decide how the entire £350 million/ week would be spent. Some of this money (science, agriculture, regional aid) would be spent in the same way, but the UK Government would probably have different priorities than the EU and target this money differently.
Even if the £350m/week figure were correct, this would still be a lie, because they were also claiming that we'd have full access to the common market. Other countries that are not in the EU but have access to the common market pay a similar amount per capita to the UK in, but then don't receive a rebate. So this claim would more accurately be phrased as 'if we left the EU, we'd have to send more money there to retain a subset of our current benefits but at least we wouldn't then get a say in how it's spent'.
He didn't write most of the Linux kernel. He wrote a really crappy kernel, which had the advantage of being the only free option for a UNIX-like system on commodity hardware (MINIX was quite expensive and not permissively licensed yet, BSD was mired in the AT&T vs UCB lawsuit, which delayed the i386 port). Other people picked it up, fixed the worst bits, and ran with it. Linus has continued to work on it, but at this stage I don't think he's even the largest single contributor, let alone responsible for more than half of the code. He was very lucky to release a kind-of-working thing at the time when there were a bunch of talented people who would prefer to improve something than start from scratch.
Mathematics is not science. Mathematics is about building internally self-consistent models, but there's no requirement that it has to be connected to any physical system. Science is about improving our understanding of the real world. If it's not testable by experiments in the real world, then it's not science.
The system in the UK is superficially similar, but entails a lot less risk. The government guarantees student loans (from a single company) of up to a fixed limit. Once you graduate, they collect interest at the rate of inflation. You begin to start paying them back when your salary passes a certain threshold and the repayments are taken off at the same time as taxes. If you don't pay them back by the time you hit retirement age, the loan is written off. If you never earn enough to hit the threshold, then you most likely didn't get any benefit from the degree and you get the education for free. If you do, then you're effectively paying a few percent more tax each year until it's paid back.
From a purely economic standpoint, the system works well: people who go to university and end up earning more pay for their degrees over a long period post graduation. The problem is psychological: working class people are more likely to be averse to debt than middle class people and so it has a slight effect of dissuading people from poorer backgrounds from applying.
Not that are particularly informative to anyone else - my typical requirement for scripting is take some data from somewhere, do some simple stats on it, and spit it out in another format. I'm happy to answer questions though.
Automation has nothing to do with the cost of employment. If companies use automation to replace $15/hr workers, they'll use it to replace $7/hr workers, and $5/hr workers, and eventually $3/hr workers.
Only if the TCO of the robots is lower than the cost of employing humans. Automation in factories stalled for about a decade because humans in India, China, and so on were cheaper than machines and so anyone building a new factory just put it where workers made $1/day and had no rights. Now the robots are even cheaper and have more consistent quality, so they're starting to replace them.
Java doesn't have sub-method reflection. The object model is very similar to (actually, slightly simpler than) Objective-C, which is AoT compiled. The only time you every look into the bytecode is during code generation. For everything else at run time, you just need class structures in your object code, something that Objective-C has happily done since the '80s. Given the number of Android devices that use AoT compilation for Java (i.e. all of them that run a vaguely recent version of Android), it's pretty hard to claim that AoT compilation for Java is not practical.
The BBC Model B was just about simple enough that one person could understand all of it, from the gate-level layout of the CPU up through the software stack. And it was just about powerful enough that you could play fun games and do real work on it (though not quite enough RAM for a useful spell checker). It's a shame that there isn't really a modern equivalent. The RPi is far too complicated (especially if you throw in Linux or similar on the software side) and the BBC Bit is too simple.
From what I remember of the book (and, admittedly, it's been a couple of decades since I last read it), the Deltas and Gammas were just as happy as the Betas. It was only the Alphas that had any issues in that regard.
There are cookies and cookies. If I go to foo.com and I get a cookie that is only readable by foo.com and is used to maintain state across visits, then that's fine. If that page on foo.com includes an i-frame that encodes the foo.com URL and contains something from bar.com that sets a cookie, and so do the next hundred sites that I visit, then I do care. I don't have any business relationship with the owners of bar.com and I don't want them to be tracking everything that I do online.
This is something that a browser could easily fix, for example by providing a separate cookie jar for each domain. If bar.com leaves a cookie while I'm looking at a page on foo.com, then it goes in the foo.com cookie jar. If I go to baz.com and it also wants to let track bar.com track me then the cookie goes in baz.com's cookie jar. Randomise things like font and plugin reporting, so that it's very hard to tie the two bar.com cookies together.
Of course, the developers of Chrome will never do something like this because their business model relies on being able to track people.
Science isn't about being right or wrong, it's about making useful predictions. If your theory lets people make predictions about a system that you can then validate and see that they were mostly correct, then it's science. Newton's laws of motion are a good example of this. They're categorically wrong, as various experiments have shown, but for things the size that a human will typically deal with the errors from failures of the model are far less than the errors from measurement. For very large, very small, or very fast things, the errors will be greater and so you need different models (and, eventually, we hope a single model that works for all scales). If your model doesn't make any predictions, then it isn't science, it's speculative fiction.
The first is the implementation of the language. You start with Smalltalk, take out the bits of Smalltalk that are difficult to compile, and then end up with an implementation of a language that is slower than something like Squeak / Pharo, which are simple bytecode interpreters. That doesn't fill anyone with confidence in the language. I can understand Ruby not being faster than a JIT-compiled Smalltalk, but there's no excuse for it not having been faster than a reasonable Smalltalk bytecode interpreter from day one.
Then there's the community. The Ruby community spent a good decade taking 30-year-old ideas and claiming that Ruby had made them possible, that Ruby developers had invented them, and this is why Ruby is so awesome. Rails is a good example of this. ORMs have existed since the '80s. WebObjects was arguably[1] the first ever web app development framework and it included EOF, which did the same thing as Rails in Objective-C (later in Java) and has had an open source reimplementation since the late '90s (GNUstepWeb, later SOPE, the latter of which is used by [Scalable] OpenGroupware.org). Oh, and WebObjects had much better developer tools than Rails, supported multithreading long before Ruby was able to run multithreaded, and was an order of magnitude or so faster.
[1] There's some disagreement, related to announcement / beta / shipping dates, but it's either the first or second.
Politicians generally claim things that they're going to attempt to do. They embellish and exaggerate, but usually campaign based on a manifesto that sets out what they'll try to do if elected. They never follow it 100%, but you expect that they'll mostly give it a pretty good go. Economic proposals in manifestos are checked by a Civil Service department and the results are published well before the election, so you know if one or more of the parties is making claims that don't add up. In contrast, the Leave campaign had no plan for what should happen if they won (and then had the gall to say that the head of the Remain campaign should have had a plan, it wasn't their job) and by promising things that they knew up-front that they couldn't deliver.
There have been Java to GCC intermediate representation translators forever, basically since like 1998. The issue there is simply that many dynamic features of Java effectively can't be translated to machine code, so only a subset of Java is translatable
That's not really true. There's nothing in Java that you can't statically compile (look at Android, for example, which now does AoT compilation for all of the Java code). The problem is that a lot of things in Java are a lot more efficient if you have realistic run-time profiling information and even more efficient if you can do some optimisations speculatively and then undo them if they were wrong. For example, Java programs typically call a lot of small methods. If you have a class that's marked final, then you can inline them in an AoT compiler, because they can never be replaced by a subclass implementation (possibly unless you use reflection? I've not looked at recent Java reflection support much), but if the class is not final then you can't. If you run the caller 1,000 times and every single time it happens to be called with an object of the same type, then you can inline that version with a very cheap check. If there's then a phase change in the program and it starts being called with a different class, then you can regenerate the code in a JIT and replace it with something more generic, or specialised for the other case.
In fact, in MANY cases, Java programs are faster than C/C++ equivalents. This is especially true for large, long-running, applications like servers and whatnot.
That's almost always due to the GC, which scales a lot better to lots of concurrent communicating threads than most malloc/free implementations combined with either shared pointers or trying to keep track of ownership.
Note that, although there's no standard C way of doing this, most modern C compilers do provide builtins for accessing the carry bit. These look like functions that return the result via a pointer and the overflow bit as a boolean return value, but when you get out of code generation they'll typically become an add (or multiply) and branch on carry.
If you really think that, then I'd suggest that you read our recent PLDI paper: Into the depths of C: elaborating the de facto standards. We asked a load of people on the C standards committee, C developers, and C compiler writers about the semantics of various C programs and got very different responses.
They don't have plenty of memory in comparison to a modern laptop or phone. Most do have plenty of memory in comparison to desktops from the 80s that were able to run BASIC interpreters at a reasonable speed. A lot of them have plenty of memory in comparison to a '70s Xerox Alto that could run an entire GUI written in a garbage-collected pure OO language.
If the function is used from another compilation unit, then you have to do that anyway (or, at least, document the calling convention and make sure that every other call site uses it). If it isn't, then most compilers will mark it as not needing to follow the public ABI and will move to a different calling convention. Some (Pro64 and derivatives, and there's a GSoC project for LLVM this year) will do inter-procedural register allocation on these functions and try to define a custom calling convention where things that the callers want to keep live are callee-save. That's very hard to do manually for anything that has multiple callers (and if it only has one caller, any modern compiler will inline it and you'll have no call overhead).
Resetting the stack is just an add to the stack pointer. If you're using any stack space in the callee, then you're doing that anyway and so it's just a different immediate value in the instruction. If you're calling anything else, then you're saving a frame pointer and so it's a cheap register-register move (basically free on a machine that does register renaming).
For what it's worth, 30% on a modern x86 is noise. You'll get that difference from very small changes. We recently were writing some assembly code to benchmark the cost of atomic ops. A simple loop that did nothing took 2.5 times as long to execute as a loop that had an extra add in the loop - the simple version hit a pathological case in register rename, which we fixed by adding an instruction zeroing a register and marking it as dead. There was a paper at ASPLOS two years ago that showed that you get a 30% delta on most programs from randomised code layouts just from different cache interaction.
We didn't have a referendum about Maastrucht, though we did have a referendum on joining the EEC in 1975 and the 'join' side had a 67% majority. If you have a 67% majority then it's pretty easy to say that you have a mandate. If you have a majority of 51.9% and a turnout of 72.2% then only 37.4% of the population actively voted for one option (and 34.7% for the other). That's pretty hard to justify is the will of the people.
Slashdot Mirror
There was another article last week pointing out that under both UK and EU law it is illegal to deprive people of their citizenship without due process. There's a legal challenge being mounted as a result. 17,410,742 people voted to leave the EU. The estimated UK population is 64,088,222, so that leaves 46,677,480 people who will be deprived of their EU citizenship without having either committed a crime for which removal of citizenship is a valid legal penalty or having explicitly disclaimed it. There's an interesting catch-22 if the challenge is upheld, because the UK can't remove EU citizenship from these people without repealing a load of laws, but it can't repeal those laws unless it first leaves the EU.
Part of the problem is that they overestimated the amount. Part of the problem is that they made the numbers seem scary (about £6/week/person seems a lot less scary given all of the things that we get in return and the actual amount is closer to £2/week.). The biggest part of the problem is that they claimed that we'd have that money back if the left, but also claimed that we'd retain access to the common market. All of the countries that have access to the common market but aren't members of the EU are paying, per capita, more than the UK after the rebate. If their bus had said 'we send the EU £350 million per week, let's pay more but have no say in how it's spent. Vote Leave.' then that would have been fine.
The most important thing is that they were saying that the UK Government would be free to decide how the entire £350 million/ week would be spent. Some of this money (science, agriculture, regional aid) would be spent in the same way, but the UK Government would probably have different priorities than the EU and target this money differently.
Even if the £350m/week figure were correct, this would still be a lie, because they were also claiming that we'd have full access to the common market. Other countries that are not in the EU but have access to the common market pay a similar amount per capita to the UK in, but then don't receive a rebate. So this claim would more accurately be phrased as 'if we left the EU, we'd have to send more money there to retain a subset of our current benefits but at least we wouldn't then get a say in how it's spent'.
He didn't write most of the Linux kernel. He wrote a really crappy kernel, which had the advantage of being the only free option for a UNIX-like system on commodity hardware (MINIX was quite expensive and not permissively licensed yet, BSD was mired in the AT&T vs UCB lawsuit, which delayed the i386 port). Other people picked it up, fixed the worst bits, and ran with it. Linus has continued to work on it, but at this stage I don't think he's even the largest single contributor, let alone responsible for more than half of the code. He was very lucky to release a kind-of-working thing at the time when there were a bunch of talented people who would prefer to improve something than start from scratch.
Mathematics is not science. Mathematics is about building internally self-consistent models, but there's no requirement that it has to be connected to any physical system. Science is about improving our understanding of the real world. If it's not testable by experiments in the real world, then it's not science.
The system in the UK is superficially similar, but entails a lot less risk. The government guarantees student loans (from a single company) of up to a fixed limit. Once you graduate, they collect interest at the rate of inflation. You begin to start paying them back when your salary passes a certain threshold and the repayments are taken off at the same time as taxes. If you don't pay them back by the time you hit retirement age, the loan is written off. If you never earn enough to hit the threshold, then you most likely didn't get any benefit from the degree and you get the education for free. If you do, then you're effectively paying a few percent more tax each year until it's paid back.
From a purely economic standpoint, the system works well: people who go to university and end up earning more pay for their degrees over a long period post graduation. The problem is psychological: working class people are more likely to be averse to debt than middle class people and so it has a slight effect of dissuading people from poorer backgrounds from applying.
Not that are particularly informative to anyone else - my typical requirement for scripting is take some data from somewhere, do some simple stats on it, and spit it out in another format. I'm happy to answer questions though.
Automation has nothing to do with the cost of employment. If companies use automation to replace $15/hr workers, they'll use it to replace $7/hr workers, and $5/hr workers, and eventually $3/hr workers.
Only if the TCO of the robots is lower than the cost of employing humans. Automation in factories stalled for about a decade because humans in India, China, and so on were cheaper than machines and so anyone building a new factory just put it where workers made $1/day and had no rights. Now the robots are even cheaper and have more consistent quality, so they're starting to replace them.
Explicit user opt-in to having their cookies shared across sites. And a visual notification of all of the third-party domains that are tracking you.
Java doesn't have sub-method reflection. The object model is very similar to (actually, slightly simpler than) Objective-C, which is AoT compiled. The only time you every look into the bytecode is during code generation. For everything else at run time, you just need class structures in your object code, something that Objective-C has happily done since the '80s. Given the number of Android devices that use AoT compilation for Java (i.e. all of them that run a vaguely recent version of Android), it's pretty hard to claim that AoT compilation for Java is not practical.
The BBC Model B was just about simple enough that one person could understand all of it, from the gate-level layout of the CPU up through the software stack. And it was just about powerful enough that you could play fun games and do real work on it (though not quite enough RAM for a useful spell checker). It's a shame that there isn't really a modern equivalent. The RPi is far too complicated (especially if you throw in Linux or similar on the software side) and the BBC Bit is too simple.
From what I remember of the book (and, admittedly, it's been a couple of decades since I last read it), the Deltas and Gammas were just as happy as the Betas. It was only the Alphas that had any issues in that regard.
There are cookies and cookies. If I go to foo.com and I get a cookie that is only readable by foo.com and is used to maintain state across visits, then that's fine. If that page on foo.com includes an i-frame that encodes the foo.com URL and contains something from bar.com that sets a cookie, and so do the next hundred sites that I visit, then I do care. I don't have any business relationship with the owners of bar.com and I don't want them to be tracking everything that I do online.
This is something that a browser could easily fix, for example by providing a separate cookie jar for each domain. If bar.com leaves a cookie while I'm looking at a page on foo.com, then it goes in the foo.com cookie jar. If I go to baz.com and it also wants to let track bar.com track me then the cookie goes in baz.com's cookie jar. Randomise things like font and plugin reporting, so that it's very hard to tie the two bar.com cookies together.
Of course, the developers of Chrome will never do something like this because their business model relies on being able to track people.
Science isn't about being right or wrong, it's about making useful predictions. If your theory lets people make predictions about a system that you can then validate and see that they were mostly correct, then it's science. Newton's laws of motion are a good example of this. They're categorically wrong, as various experiments have shown, but for things the size that a human will typically deal with the errors from failures of the model are far less than the errors from measurement. For very large, very small, or very fast things, the errors will be greater and so you need different models (and, eventually, we hope a single model that works for all scales). If your model doesn't make any predictions, then it isn't science, it's speculative fiction.
The first is the implementation of the language. You start with Smalltalk, take out the bits of Smalltalk that are difficult to compile, and then end up with an implementation of a language that is slower than something like Squeak / Pharo, which are simple bytecode interpreters. That doesn't fill anyone with confidence in the language. I can understand Ruby not being faster than a JIT-compiled Smalltalk, but there's no excuse for it not having been faster than a reasonable Smalltalk bytecode interpreter from day one.
Then there's the community. The Ruby community spent a good decade taking 30-year-old ideas and claiming that Ruby had made them possible, that Ruby developers had invented them, and this is why Ruby is so awesome. Rails is a good example of this. ORMs have existed since the '80s. WebObjects was arguably[1] the first ever web app development framework and it included EOF, which did the same thing as Rails in Objective-C (later in Java) and has had an open source reimplementation since the late '90s (GNUstepWeb, later SOPE, the latter of which is used by [Scalable] OpenGroupware.org). Oh, and WebObjects had much better developer tools than Rails, supported multithreading long before Ruby was able to run multithreaded, and was an order of magnitude or so faster.
[1] There's some disagreement, related to announcement / beta / shipping dates, but it's either the first or second.
For small programs, compiling C++ at -O0 takes under a second and the result runs faster than any interpreted language.
Politicians generally claim things that they're going to attempt to do. They embellish and exaggerate, but usually campaign based on a manifesto that sets out what they'll try to do if elected. They never follow it 100%, but you expect that they'll mostly give it a pretty good go. Economic proposals in manifestos are checked by a Civil Service department and the results are published well before the election, so you know if one or more of the parties is making claims that don't add up. In contrast, the Leave campaign had no plan for what should happen if they won (and then had the gall to say that the head of the Remain campaign should have had a plan, it wasn't their job) and by promising things that they knew up-front that they couldn't deliver.
There have been Java to GCC intermediate representation translators forever, basically since like 1998. The issue there is simply that many dynamic features of Java effectively can't be translated to machine code, so only a subset of Java is translatable
That's not really true. There's nothing in Java that you can't statically compile (look at Android, for example, which now does AoT compilation for all of the Java code). The problem is that a lot of things in Java are a lot more efficient if you have realistic run-time profiling information and even more efficient if you can do some optimisations speculatively and then undo them if they were wrong. For example, Java programs typically call a lot of small methods. If you have a class that's marked final, then you can inline them in an AoT compiler, because they can never be replaced by a subclass implementation (possibly unless you use reflection? I've not looked at recent Java reflection support much), but if the class is not final then you can't. If you run the caller 1,000 times and every single time it happens to be called with an object of the same type, then you can inline that version with a very cheap check. If there's then a phase change in the program and it starts being called with a different class, then you can regenerate the code in a JIT and replace it with something more generic, or specialised for the other case.
In fact, in MANY cases, Java programs are faster than C/C++ equivalents. This is especially true for large, long-running, applications like servers and whatnot.
That's almost always due to the GC, which scales a lot better to lots of concurrent communicating threads than most malloc/free implementations combined with either shared pointers or trying to keep track of ownership.
Note that, although there's no standard C way of doing this, most modern C compilers do provide builtins for accessing the carry bit. These look like functions that return the result via a pointer and the overflow bit as a boolean return value, but when you get out of code generation they'll typically become an add (or multiply) and branch on carry.
If you really think that, then I'd suggest that you read our recent PLDI paper: Into the depths of C: elaborating the de facto standards. We asked a load of people on the C standards committee, C developers, and C compiler writers about the semantics of various C programs and got very different responses.
They don't have plenty of memory in comparison to a modern laptop or phone. Most do have plenty of memory in comparison to desktops from the 80s that were able to run BASIC interpreters at a reasonable speed. A lot of them have plenty of memory in comparison to a '70s Xerox Alto that could run an entire GUI written in a garbage-collected pure OO language.
If the function is used from another compilation unit, then you have to do that anyway (or, at least, document the calling convention and make sure that every other call site uses it). If it isn't, then most compilers will mark it as not needing to follow the public ABI and will move to a different calling convention. Some (Pro64 and derivatives, and there's a GSoC project for LLVM this year) will do inter-procedural register allocation on these functions and try to define a custom calling convention where things that the callers want to keep live are callee-save. That's very hard to do manually for anything that has multiple callers (and if it only has one caller, any modern compiler will inline it and you'll have no call overhead).
Resetting the stack is just an add to the stack pointer. If you're using any stack space in the callee, then you're doing that anyway and so it's just a different immediate value in the instruction. If you're calling anything else, then you're saving a frame pointer and so it's a cheap register-register move (basically free on a machine that does register renaming).
For what it's worth, 30% on a modern x86 is noise. You'll get that difference from very small changes. We recently were writing some assembly code to benchmark the cost of atomic ops. A simple loop that did nothing took 2.5 times as long to execute as a loop that had an extra add in the loop - the simple version hit a pathological case in register rename, which we fixed by adding an instruction zeroing a register and marking it as dead. There was a paper at ASPLOS two years ago that showed that you get a 30% delta on most programs from randomised code layouts just from different cache interaction.
We didn't have a referendum about Maastrucht, though we did have a referendum on joining the EEC in 1975 and the 'join' side had a 67% majority. If you have a 67% majority then it's pretty easy to say that you have a mandate. If you have a majority of 51.9% and a turnout of 72.2% then only 37.4% of the population actively voted for one option (and 34.7% for the other). That's pretty hard to justify is the will of the people.