Silicon Valley though is also (for the most part) the perfect example of companies *not* abusing H1Bs though.
In general, tech sector H1Bs in the bay area are extremely highly paid specialists who have been brought in to solve problems that require a very specific skill set. The problem of companies bringing in unskilled indian "contractors" to replace american workers en-mass has really not sprung up there.
Notice how neither Hertz nor Disney is a Silicon Valley tech company;).
The amount of data you can fit in a normal drive would be a good measure. Some googling says the largest 3.5" HDD is 10TB; the largest 3.5" SSD is 16TB.
I can buy that optional chaining (not optionals) encourages lots and lots of redundant null checking. That said, no more than obj-c, which already did redundant null checking on every single message send. Optional chaining effectively is an obj-c compatibility measure, to mimic it's "it's safe to send messages to nil" behaviour.
Optional types rather point out that obj-c's behaviour was weird here, and that you should make your best effort to prove to the compiler that something really isn't null before sending messages to it.
Again, no. It encourages putting the check in exactly one well structured place:
func f(x : Object?) {// We know that the check has not happened yet, x may be null
guard let y = x else {
return;
}
g(y) }
func g(x : Object) {// The lack of a ? documents that by this point we expect that the check must of happened. Not only that but it asks the compiler to enforce that it must have happened
doShitWithX(x) }
The type system enforces that a) we definitely do check, and b) that the person writing g, or doShitWithX does not need to check, because it's been documented (in a provable way) that the check has already happened by that point.
There's no encouragement of multiple checks at all. Instead, there's encouragement that you make a single check, and then document explicitly where that check is, in a way that the compiler can verify.
Not having optionals, instead encourages you to make multiple checks, as the author of g, or doShitWithX, will feel the need to assert preconditions in their functions, because they have no good way of informing their callers that they should never receive null.
Right, I mean, that's exactly why they use them for heat resistant coatings on vehicles that need to reenter the atmosphere.
Oh wait no, that's because *you're* wrong, and certain ceramics (notably, ones without porosity, and without air or water trapped inside them) are extremely good at resisting heat and heat changes.
Uhhh, no, no they don't - they actually encourage exactly the opposite. They let the type system define exactly where the well-structured boundary between "I've not checked for null here" and "I have checked for null here" is.
Wait, are you suggesting that it should optimise out the checks?
You seem to be missing the important bit of this... You *need* to check for those null pointers. You always did need to check for them before you had optionals making sure that you did. It's flat out a bug to not check. Saying "it's faster to not check" is irrelevant - checking is necessary for program correctness.
Yes, I did. The author does say a "vocal minority", but that doesn't change the fact that he's implying that software developers have a much higher chance of being "socially underdeveloped" than any other profession. Their entire argument rests on the notion that there's a larger than average proportion of socially underdeveloped people in the open source community.
So yes, yes they really did generalise a large group of people and call them socially underdeveloped.
Why on earth would optionals be considered a bad thing? Not only having the compiler check that you don't ever make a null pointer dereference (probably the single most common type of bug that exists); but also extending that checking to any value that may or may not exist. What possible justification is there to not do that?
Mostly because of the generally non-nice, aggressive, "it's all your fault" way that it was put. The social issue on display here is the article's author generalising a large group of people, and collectively calling them socially underdeveloped. It's unsurprising that that gets a negative response, in much the same way as generalising all women, and calling them crap at technology gets an unsurprisingly negative response.
That would indeed be the "smarter" thing to do in terms of pure engineering. In terms of company morale though, possibly not. It may be a much smarter management decision may well be to help everyone to realise how awesome an achievement they were just part of, and to keep company morale up, because it will increase productivity enough to offset the engineering benefit.
So what you're saying is "you could do all the things you do today, if you bought massively more powerful hardware, because I'm too lazy to write code that runs efficiency"
The fact is that native code, with manual (or compiler inserted) memory management will always be significantly more efficient than crappy web apps and their interpreted (even JITed), garbage collected mess.
You shouldn't be saying "Maybe phones with 3GB+ RAM will change this" but instead "Hey, why does my code require 3GB of RAM to run even half reasonably, when that other guy's code runs natively on a device with 1GB of RAM"
In my opinion the cricial issue is just how people see their life and work. If they used to think that working is part of their life then they will keep it. If they decide to live without working then the balance in economy will be lost.
Yup, thankfully, that's offset by two useful things:
1) You can tweak the value of the minimum income to a point where people are willing to work 2) People have an inherent need to do *something*. They will go out and find work. What they won't do, is go out and work for someone abusive, so it will provide a soft pressure for abusive companies to actually provide people with an income they deserve.
The thing that worries me is actually that all it will do is provide a way of siphoning off a chunk of tax to the rich homeowners. The reason - landlords will immediately know that everyone has $700 "extra" to live off. Every rental property will suddenly become $700 a month more expensive per bedroom. Suddenly all the rich get an extra $700 a month per person renting a house they own, and no one gets a basic income at all.
Interesting that you chose the cheapest HDD you could, but a pretty expensive SSD.
SSDs are at about $240/TB. That's still pretty expensive, but it's still only 7.3x more than HDDs atm.
More so, your "20x or more 10 years ago" is technically correct, thanks to the "or more". In reality though, a decade ago 512*MB* of flash storage (not even a true SSD) cost $40, aka $80,000 per TB. So the gap has come down from 2400 times more expensive per GB to 7 times more expensive per GB in a decade.
In fact, just one year ago, a 128GB SSD cost you $140 - aka $1,120 per TB, or 33 times more expensive.
Based on the rate of decline in the gap, it's not hard to see why people are saying SSDs are going to get into the price range of HDDs pretty soon. Based on the current progression in the cost of SSDs it'll be about 1.5 to 2 years.
No, software developers are people who are more than just code monkeys. They are people who can understand requirements, design things, and develop the entire architecture, rather than just bashing out a program.
Bezos's launcher only reaches 62km altitude, at mach 3. It's less than half the height of Falcon 9 stage 1. It does not do a gravity turn due to the fact that it doesn't get to orbit. All of these make sticking a landing much much easier. If you want Space X to just go up, back down, and land it (like bezos did), then look at 2013, when they did that. Now they've also beaten Bezos to landing the launcher for an orbital space craft.
Note, things like the launcher being twice as tall as Bezos' isn't a case of "well, Space X made a poor design choice to make it that tall"... Instead, it's a case of "if you want to reach orbit, you need low drag, so you need a long thin space craft".
Slashdot Mirror
Silicon Valley though is also (for the most part) the perfect example of companies *not* abusing H1Bs though.
In general, tech sector H1Bs in the bay area are extremely highly paid specialists who have been brought in to solve problems that require a very specific skill set. The problem of companies bringing in unskilled indian "contractors" to replace american workers en-mass has really not sprung up there.
Notice how neither Hertz nor Disney is a Silicon Valley tech company ;).
Right - then you just leak information to the VPN host.
Mini HDMI is larger than USB-C.
No, the summary is confusing "games" and "board states". It explicitly states positions, not games.
The amount of data you can fit in a normal drive would be a good measure. Some googling says the largest 3.5" HDD is 10TB; the largest 3.5" SSD is 16TB.
Why would it require going back to 5" drives? SSDs have higher data density than HDDs, they just have lower data density per dollar.
I can buy that optional chaining (not optionals) encourages lots and lots of redundant null checking. That said, no more than obj-c, which already did redundant null checking on every single message send. Optional chaining effectively is an obj-c compatibility measure, to mimic it's "it's safe to send messages to nil" behaviour.
Optional types rather point out that obj-c's behaviour was weird here, and that you should make your best effort to prove to the compiler that something really isn't null before sending messages to it.
Again, no. It encourages putting the check in exactly one well structured place:
func f(x : Object?) { // We know that the check has not happened yet, x may be null
guard let y = x else {
return;
}
g(y)
}
func g(x : Object) { // The lack of a ? documents that by this point we expect that the check must of happened. Not only that but it asks the compiler to enforce that it must have happened
doShitWithX(x)
}
The type system enforces that a) we definitely do check, and b) that the person writing g, or doShitWithX does not need to check, because it's been documented (in a provable way) that the check has already happened by that point.
There's no encouragement of multiple checks at all. Instead, there's encouragement that you make a single check, and then document explicitly where that check is, in a way that the compiler can verify.
Not having optionals, instead encourages you to make multiple checks, as the author of g, or doShitWithX, will feel the need to assert preconditions in their functions, because they have no good way of informing their callers that they should never receive null.
Right, I mean, that's exactly why they use them for heat resistant coatings on vehicles that need to reenter the atmosphere.
Oh wait no, that's because *you're* wrong, and certain ceramics (notably, ones without porosity, and without air or water trapped inside them) are extremely good at resisting heat and heat changes.
Uhhh, no, no they don't - they actually encourage exactly the opposite. They let the type system define exactly where the well-structured boundary between "I've not checked for null here" and "I have checked for null here" is.
Wait, are you suggesting that it should optimise out the checks?
You seem to be missing the important bit of this... You *need* to check for those null pointers. You always did need to check for them before you had optionals making sure that you did. It's flat out a bug to not check. Saying "it's faster to not check" is irrelevant - checking is necessary for program correctness.
You realise that swift optimises them away into use of a sentinel in pretty much all cases, right? (usually, actually a null pointer).
Uhhh, rust's way of dealing with pointers that might be null is optionals...
https://doc.rust-lang.org/std/...
Yes, I did. The author does say a "vocal minority", but that doesn't change the fact that he's implying that software developers have a much higher chance of being "socially underdeveloped" than any other profession. Their entire argument rests on the notion that there's a larger than average proportion of socially underdeveloped people in the open source community.
So yes, yes they really did generalise a large group of people and call them socially underdeveloped.
Why on earth would optionals be considered a bad thing? Not only having the compiler check that you don't ever make a null pointer dereference (probably the single most common type of bug that exists); but also extending that checking to any value that may or may not exist. What possible justification is there to not do that?
Mostly because of the generally non-nice, aggressive, "it's all your fault" way that it was put. The social issue on display here is the article's author generalising a large group of people, and collectively calling them socially underdeveloped. It's unsurprising that that gets a negative response, in much the same way as generalising all women, and calling them crap at technology gets an unsurprisingly negative response.
That would indeed be the "smarter" thing to do in terms of pure engineering. In terms of company morale though, possibly not. It may be a much smarter management decision may well be to help everyone to realise how awesome an achievement they were just part of, and to keep company morale up, because it will increase productivity enough to offset the engineering benefit.
So what you're saying is "you could do all the things you do today, if you bought massively more powerful hardware, because I'm too lazy to write code that runs efficiency"
The fact is that native code, with manual (or compiler inserted) memory management will always be significantly more efficient than crappy web apps and their interpreted (even JITed), garbage collected mess.
You shouldn't be saying "Maybe phones with 3GB+ RAM will change this" but instead "Hey, why does my code require 3GB of RAM to run even half reasonably, when that other guy's code runs natively on a device with 1GB of RAM"
In my opinion the cricial issue is just how people see their life and work. If they used to think that working is part of their life then they will keep it. If they decide to live without working then the balance in economy will be lost.
Yup, thankfully, that's offset by two useful things:
1) You can tweak the value of the minimum income to a point where people are willing to work
2) People have an inherent need to do *something*. They will go out and find work. What they won't do, is go out and work for someone abusive, so it will provide a soft pressure for abusive companies to actually provide people with an income they deserve.
The thing that worries me is actually that all it will do is provide a way of siphoning off a chunk of tax to the rich homeowners. The reason - landlords will immediately know that everyone has $700 "extra" to live off. Every rental property will suddenly become $700 a month more expensive per bedroom. Suddenly all the rich get an extra $700 a month per person renting a house they own, and no one gets a basic income at all.
If you'd even read the summary, you would see that this is a cost saving measure, it's going to be cheaper, not more expensive.
The issue is with what happens when the SSD stops having the voltage to write half way through writing something.
Thankfully, journalling file systems solved this problem years ago though.
Interesting that you chose the cheapest HDD you could, but a pretty expensive SSD.
SSDs are at about $240/TB. That's still pretty expensive, but it's still only 7.3x more than HDDs atm.
More so, your "20x or more 10 years ago" is technically correct, thanks to the "or more". In reality though, a decade ago 512*MB* of flash storage (not even a true SSD) cost $40, aka $80,000 per TB. So the gap has come down from 2400 times more expensive per GB to 7 times more expensive per GB in a decade.
In fact, just one year ago, a 128GB SSD cost you $140 - aka $1,120 per TB, or 33 times more expensive.
Based on the rate of decline in the gap, it's not hard to see why people are saying SSDs are going to get into the price range of HDDs pretty soon. Based on the current progression in the cost of SSDs it'll be about 1.5 to 2 years.
No, software developers are people who are more than just code monkeys. They are people who can understand requirements, design things, and develop the entire architecture, rather than just bashing out a program.
Bezos's launcher only reaches 62km altitude, at mach 3. It's less than half the height of Falcon 9 stage 1. It does not do a gravity turn due to the fact that it doesn't get to orbit. All of these make sticking a landing much much easier. If you want Space X to just go up, back down, and land it (like bezos did), then look at 2013, when they did that. Now they've also beaten Bezos to landing the launcher for an orbital space craft.
Note, things like the launcher being twice as tall as Bezos' isn't a case of "well, Space X made a poor design choice to make it that tall"... Instead, it's a case of "if you want to reach orbit, you need low drag, so you need a long thin space craft".
The reason that a carrier landing is harder is because the runway is shorter. With a vertical landing vehicle, it's a non-issue.
That said, I'm pretty sure that Space X's position is - if something's stuck, you can't land.