If they were being pushed out of land they owned, you might have a point.
The problem is when the initial conditions are concentrated ownership. If the hypothetical impoverished country has a feudal system (or similar) where all of the land is owned by a few dozen lords. Now the Americans going over there buy land from the lord in relatively small parcels, allowing him to turn his wealth into liquid form and removing the land that his serfs lived on. So what do the serfs do? They didn't own the land and they're now displaced. They weren't lucky enough to be born owning land so they get nothing.
It's not like most of the people in the original poster's example chose not to own a house. They rent because they didn't inherit enough wealth to own somewhere to live.
The C++11 specification was explicitly written to permit garbage collection and includes standard library functions for providing hints to a garbage collector.
Not true. In C++11 you have std::make_shared, which allocates an object and the metadata block for a std::shared_ptr in a single block, giving you a lower-overhead mechanism for creating a std::shared_ptr. C++14 also introduced std::make_unique, which doesn't save anything over calling new and then casting to a std::unique_ptr, but make it possible to write code without any need to directly call new. In C++14, there is absolutely no reason to see a new or delete in the code outside of the standard library implementation. If you're writing one then you're doing it wrong.
"Smart pointers" are great -- if you don't care about performance (in which case, why are you not using Java?). If the object is owned by one thread, it's just sloppy to put in the overhead of smart pointers to make your life easy.
If an object has a single unique owner, then std::unique_ptr has no run-time overhead and will ensure that the object is correctly deleted even in the presence of exceptions. I agree with the grandparent: any object that isn't allocated on the stack should be created with std::make_shared or std::make_unique.
If you can't be replaced, then you can't be promoted. Do you really want to be maintaining the same program for the rest of your life? And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?
making the code run faster qualifies if it's not running fast enough yet
And then only if backed up by realistic macrobenchmarks. There are a lot of things in C++ that have interesting performance characteristics (templates allow more inlining, so make microbenchmarks faster but can cause you to run out of i-cache and make the whole program slower, virtual functions prevent inlining unless the compiler can do devirtualisation, but are actually slightly faster to call than cross-library calls via a PLT if they're not inlined). Generally, algorithmic improvements will make a bigger difference than any language feature. The main reason for using templates should be to eliminate copy-and-paste coding, not to improve performance.
How did they control for biases coming from parents? Research that I've read shows that gender stereotypes start to be instilled within the first few days after a child is born. Unless they're testing with children that have never seen a toy of any kind before, then the toy experiments are not detecting biological biases, they're picking up on a mix of inherited and learned responses. There's a lot of very bad science done to try to claim that there are things that girls like and things that boys like, ignoring the fact that the things that girls like vary wildly between countries and even over time in the same country (for example, blue was a girls' colour and ping a boys' colour in most of Europe until 1-2 centuries ago, and horses have swung between the two as a stereotypical interest several times).
How times have changed. Someone posts and old copypasta troll and gets dozens of serious responses. If any post deserves a +5 Troll mod, it's this one. Beautifully done sir, though perhaps a sad reflection on what's left of this community.
It's not a problem for floating point, where division by zero is well defined (it's a NaN value). And division by almost-zero is not a problem in floating point either, though if you're going down one of the pipelines for dealing with subnormal values then be aware that it's likely 10-100 times slower than normal floating point calculations.
It took a lot longer than a few weeks to break even for me, but it was less than a year. Allowing different thermostat settings at different times and on different days made the house quite a lot more efficient.
I'm surprised that it's taken this long. I've thought that MS and Apple should have been incorporating aggressive anti-tracking and ad blocking capabilities into IE and Safari for a few years, because neither company makes much money from ads, both could easily spin it as a user-centric decision, and it would hurt Google a lot.
The BIOS almost certainly won't enable any of the software-controlled power management features of your CPU. If it's a pre-EFI BIOS then it's also running in real mode and even if it's EFI it's likely to be running in a polling loop rather than relying on interrupts for user input.
How many times have you used Notepad/Wordpad instead of Word?
I use the Mac equivalent, TextEdit, quite often for jotting down quick notes and for quickly opening text files (including rich text and Word docs where I don't really care about the formatting). TextEdit is a very thin wrapper around the NSTextView class, and so is the same sort of not-quite-demo-app as WordPad, which is a thin wrapper around Microsoft's rich text editor control. I have Word, Pages, OpenOffice and LibreOffice installed, but I probably use TextEdit more than all of them combined, because for most simple things it just gets out of the way.
Mozilla derives its income from things like search placement, which are paid proportionally to the number of users, so effectively anyone who uses Firefox and doesn't change the default search engine is a paying customer.
Open source, like proprietary software, is supposed to be about what the contributors want. In the proprietary COTS model, it's easy to identify the contributors: they're the ones handing over money in exchange for the product. In the bespoke model - proprietary or open - it's usually the person paying the developers salary. In the mass-market open source model, it's much harder (and may be a mixture of volunteer devs / doc writers / bug reporters and so on, as well as some people funding the project). For Mozilla, most of the work is done by people who are paid, but their salaries come from from an income stream (money from the default search provider and so on) that makes it quite difficult to see who the contributors are. Technically, they're probably the users, since that's essentially how Moz Corp gets its money, but via a lot of layers of indirection.
Biking when it's snowy or icy isn't that dangerous, as long as your bike is in good condition and you've had a lot of practice cycling. I suspect that neither of these are entirely true for users of this scheme.
Keep burning them at current rates, and by 2100 we'll have run out. The headline really should have been 'Politicians promise their countries will do something that they'd have to do anyway, long after they'll have retired'
That's more or less the system in the UK. You get a loan that charges interest at the rate of inflation, plus some government funding if you qualify (lower income people only). The loans are guaranteed by the government and the interest and repayments are collected at the same time as taxes and assessed based on income (so you don't start paying them back until you're earning above a certain rate). The loans are issued by a not-for-profit company, effectively by the government though separate for accounting purposes. The government bets that having more people with degrees will increase tax revenues in the future. There is a fairly good market for rate-of-inflation investments (i.e. the other side of the loans), if they come with very low risk. Generally, if you have lots of money you want to have a reasonable chunk of it in something safe and have a smaller part in high-risk, high-return investments. Government-backed loans make a solid part of such a portfolio.
Tuition fees are also capped by the government (currently at £9K/year, which is a bit excessive. When I was a student the cap was £3K, which was a lot more reasonable. Unfortunately, the last government cut government funding at the same time that they put up the maximum requirement, effectively forcing most universities to raise their fees to £9K to keep the same per-student income. The Scottish and Welsh governments both pay the fees, so they really only apply to English students, which also causes a bit of friction).
Tuition may only be $10K/year, but how much are you living expenses as a student? You're likely in shared accommodation and eating cheap food, but can you do it for under $5K/year? That adds another $20K. Still not $100K, but edging in that direction.
There was a study a couple of years ago from Harvard (and covered on Slashdot) that put the optimum price for maximising profit at 5/track. At that price, people don't think about buying music - they'll happily buy an album because they heard a bit of a song and liked it or a friend recommended the artist. The increase in sales, the study claimed, would more than offset the reduction in per-sale profit.
Nope (also [citation needed]). The go compiler is fast because it doesn't use modules/header files.
There are three compilers for Go, one based on the Plan 9 stuff, one a GCC front end, and one an LLVM front end. True, none of them use header files, but this is really something that doesn't affect C-family languages if you use precompiled headers. The Plan 9 implementation is fast because it does a tiny subset of the optimisations that GCC or LLVM would do.
The GCC and LLVM-based compilers are have similar compile-time performance to C or Objective-C. They're only faster in comparison to C++ because they don't do any compile-time specialisation (which, by the way, something like a.NET CLR or JVM will do in the JIT, but which Go never does). In C++, you pay a price in compile time for better run time[1] if you use templates or pay it at run time if you use virtual functions, in Go you pay the price at run time and have no alternative. Unless you're the person implementing the generic Map type (though the Map can't be usefully parameterised, so you often end up paying it as a user of this type too).
Go does a lot of nice things (channels, interfaces, and so on), but it is frustrating when a new language includes problems that other languages fixed decades ago. Share via communicating is a sensible pattern, but a new language for parallelism that doesn't make it trivial to enforce shared xor mutable is embarrassing. Erlang had this right from the start and Pony does it in a very nice way.
[1] Unless you end up blowing away your i-cache. It's true that a lot of C++ programmers will overuse templates and end up sacrificing compile time for no measurable run-time benefit, but at least when you actually want to retain most of the source flexibility of dynamic dispatch without the run-time overhead then you can.
Add to that, Go and Swift are pretty small languages. Learning either is something that a moderately competent programmer ought to be able to do in a few weeks. Neither is sufficiently different to other languages that there's a big cognitive jump. The difficult thing is always learning new libraries and frameworks, not learning a new language (well, unless the new language is C++, where after a decade of daily use developers are still not surprised to come across a language feature that they've never seen before).
Slashdot Mirror
If they were being pushed out of land they owned, you might have a point.
The problem is when the initial conditions are concentrated ownership. If the hypothetical impoverished country has a feudal system (or similar) where all of the land is owned by a few dozen lords. Now the Americans going over there buy land from the lord in relatively small parcels, allowing him to turn his wealth into liquid form and removing the land that his serfs lived on. So what do the serfs do? They didn't own the land and they're now displaced. They weren't lucky enough to be born owning land so they get nothing.
It's not like most of the people in the original poster's example chose not to own a house. They rent because they didn't inherit enough wealth to own somewhere to live.
The C++11 specification was explicitly written to permit garbage collection and includes standard library functions for providing hints to a garbage collector.
C++ is never the right tool for the job, but for a lot of jobs the right tool doesn't exist and C++ will work.
No it doesn't. It depends on the ABI and the CPU that you're using, but the compiler makes no difference at all.
Not true. In C++11 you have std::make_shared, which allocates an object and the metadata block for a std::shared_ptr in a single block, giving you a lower-overhead mechanism for creating a std::shared_ptr. C++14 also introduced std::make_unique, which doesn't save anything over calling new and then casting to a std::unique_ptr, but make it possible to write code without any need to directly call new. In C++14, there is absolutely no reason to see a new or delete in the code outside of the standard library implementation. If you're writing one then you're doing it wrong.
"Smart pointers" are great -- if you don't care about performance (in which case, why are you not using Java?). If the object is owned by one thread, it's just sloppy to put in the overhead of smart pointers to make your life easy.
If an object has a single unique owner, then std::unique_ptr has no run-time overhead and will ensure that the object is correctly deleted even in the presence of exceptions. I agree with the grandparent: any object that isn't allocated on the stack should be created with std::make_shared or std::make_unique.
If you can't be replaced, then you can't be promoted. Do you really want to be maintaining the same program for the rest of your life? And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?
making the code run faster qualifies if it's not running fast enough yet
And then only if backed up by realistic macrobenchmarks. There are a lot of things in C++ that have interesting performance characteristics (templates allow more inlining, so make microbenchmarks faster but can cause you to run out of i-cache and make the whole program slower, virtual functions prevent inlining unless the compiler can do devirtualisation, but are actually slightly faster to call than cross-library calls via a PLT if they're not inlined). Generally, algorithmic improvements will make a bigger difference than any language feature. The main reason for using templates should be to eliminate copy-and-paste coding, not to improve performance.
How did they control for biases coming from parents? Research that I've read shows that gender stereotypes start to be instilled within the first few days after a child is born. Unless they're testing with children that have never seen a toy of any kind before, then the toy experiments are not detecting biological biases, they're picking up on a mix of inherited and learned responses. There's a lot of very bad science done to try to claim that there are things that girls like and things that boys like, ignoring the fact that the things that girls like vary wildly between countries and even over time in the same country (for example, blue was a girls' colour and ping a boys' colour in most of Europe until 1-2 centuries ago, and horses have swung between the two as a stereotypical interest several times).
for the vast majority of the Chinese people, over 90%, do not believe in the effectiveness of the rhino horns
So that's a target market of only 136 million?
with the exception of those living in the Hong Kong and surrounding region (mainly Guangzhou)
Oh, and they're only concentrated in one of the wealthiest areas? Definitely not a problem then.
How times have changed. Someone posts and old copypasta troll and gets dozens of serious responses. If any post deserves a +5 Troll mod, it's this one. Beautifully done sir, though perhaps a sad reflection on what's left of this community.
It's not a problem for floating point, where division by zero is well defined (it's a NaN value). And division by almost-zero is not a problem in floating point either, though if you're going down one of the pipelines for dealing with subnormal values then be aware that it's likely 10-100 times slower than normal floating point calculations.
It took a lot longer than a few weeks to break even for me, but it was less than a year. Allowing different thermostat settings at different times and on different days made the house quite a lot more efficient.
I'm surprised that it's taken this long. I've thought that MS and Apple should have been incorporating aggressive anti-tracking and ad blocking capabilities into IE and Safari for a few years, because neither company makes much money from ads, both could easily spin it as a user-centric decision, and it would hurt Google a lot.
The BIOS almost certainly won't enable any of the software-controlled power management features of your CPU. If it's a pre-EFI BIOS then it's also running in real mode and even if it's EFI it's likely to be running in a polling loop rather than relying on interrupts for user input.
How many times have you used Notepad/Wordpad instead of Word?
I use the Mac equivalent, TextEdit, quite often for jotting down quick notes and for quickly opening text files (including rich text and Word docs where I don't really care about the formatting). TextEdit is a very thin wrapper around the NSTextView class, and so is the same sort of not-quite-demo-app as WordPad, which is a thin wrapper around Microsoft's rich text editor control. I have Word, Pages, OpenOffice and LibreOffice installed, but I probably use TextEdit more than all of them combined, because for most simple things it just gets out of the way.
Mozilla derives its income from things like search placement, which are paid proportionally to the number of users, so effectively anyone who uses Firefox and doesn't change the default search engine is a paying customer.
Open source, like proprietary software, is supposed to be about what the contributors want. In the proprietary COTS model, it's easy to identify the contributors: they're the ones handing over money in exchange for the product. In the bespoke model - proprietary or open - it's usually the person paying the developers salary. In the mass-market open source model, it's much harder (and may be a mixture of volunteer devs / doc writers / bug reporters and so on, as well as some people funding the project). For Mozilla, most of the work is done by people who are paid, but their salaries come from from an income stream (money from the default search provider and so on) that makes it quite difficult to see who the contributors are. Technically, they're probably the users, since that's essentially how Moz Corp gets its money, but via a lot of layers of indirection.
Biking when it's snowy or icy isn't that dangerous, as long as your bike is in good condition and you've had a lot of practice cycling. I suspect that neither of these are entirely true for users of this scheme.
Keep burning them at current rates, and by 2100 we'll have run out. The headline really should have been 'Politicians promise their countries will do something that they'd have to do anyway, long after they'll have retired'
Tuition fees are also capped by the government (currently at £9K/year, which is a bit excessive. When I was a student the cap was £3K, which was a lot more reasonable. Unfortunately, the last government cut government funding at the same time that they put up the maximum requirement, effectively forcing most universities to raise their fees to £9K to keep the same per-student income. The Scottish and Welsh governments both pay the fees, so they really only apply to English students, which also causes a bit of friction).
Tuition may only be $10K/year, but how much are you living expenses as a student? You're likely in shared accommodation and eating cheap food, but can you do it for under $5K/year? That adds another $20K. Still not $100K, but edging in that direction.
There was a study a couple of years ago from Harvard (and covered on Slashdot) that put the optimum price for maximising profit at 5/track. At that price, people don't think about buying music - they'll happily buy an album because they heard a bit of a song and liked it or a friend recommended the artist. The increase in sales, the study claimed, would more than offset the reduction in per-sale profit.
Nope (also [citation needed]). The go compiler is fast because it doesn't use modules/header files.
There are three compilers for Go, one based on the Plan 9 stuff, one a GCC front end, and one an LLVM front end. True, none of them use header files, but this is really something that doesn't affect C-family languages if you use precompiled headers. The Plan 9 implementation is fast because it does a tiny subset of the optimisations that GCC or LLVM would do.
The GCC and LLVM-based compilers are have similar compile-time performance to C or Objective-C. They're only faster in comparison to C++ because they don't do any compile-time specialisation (which, by the way, something like a .NET CLR or JVM will do in the JIT, but which Go never does). In C++, you pay a price in compile time for better run time[1] if you use templates or pay it at run time if you use virtual functions, in Go you pay the price at run time and have no alternative. Unless you're the person implementing the generic Map type (though the Map can't be usefully parameterised, so you often end up paying it as a user of this type too).
Go does a lot of nice things (channels, interfaces, and so on), but it is frustrating when a new language includes problems that other languages fixed decades ago. Share via communicating is a sensible pattern, but a new language for parallelism that doesn't make it trivial to enforce shared xor mutable is embarrassing. Erlang had this right from the start and Pony does it in a very nice way.
[1] Unless you end up blowing away your i-cache. It's true that a lot of C++ programmers will overuse templates and end up sacrificing compile time for no measurable run-time benefit, but at least when you actually want to retain most of the source flexibility of dynamic dispatch without the run-time overhead then you can.
Add to that, Go and Swift are pretty small languages. Learning either is something that a moderately competent programmer ought to be able to do in a few weeks. Neither is sufficiently different to other languages that there's a big cognitive jump. The difficult thing is always learning new libraries and frameworks, not learning a new language (well, unless the new language is C++, where after a decade of daily use developers are still not surprised to come across a language feature that they've never seen before).