@Cerberus Yes, exactly what I said. When Google is selling it, they sell it at their price. When Google isn't selling it, someone else is, and they sell it at the higher price.
So my suspicion is that Google is prevented from, or not interested in selling phones directly in every European country.
@Cerberus Let's say a country requires you to jump through certain regulatory hoops before you can sell a cellphone. Like, the USA requires FCC certification.
Now let's say that Google wants to sell in your country, but the regulatory costs or other startup costs are too high to justify it at this time.
Then it would be reasonable for them to contract sales out to someone else.
That person can't get the phones for Google's price because they have to mark it up to be profitable.
@Cerberus Why hasn't Google launched ALL its products in every country? Evil conspiracy? Or just "it takes time and money and they haven't done it yet"
@Mr.ShinyandNew安宇 It's LG that's selling the phone here. And why would they have to mark it up while Google would not? Besides, "have" is just not the right word: they make a profit either way, the BOM is likely under € 200.
@Mr.ShinyandNew安宇 I rather think it is because they want to make sure those markets are well served where Google sells music and stuff through their shop. And they didn't want to make enough of an investment to make enough phones for the entire world.
@Mr.ShinyandNew安宇 Of course there are, but those aren't marginal costs, and only those are relevant to the decision "shall we sell in Holland or not?". There will be some other marginal costs on top of the BOM + manufacturing, but not that many, and certainly nothing remotely close to the € 150 that you need to arrive at the German price (€ 350, presumably). And of course there is the Canadian price as exhibit A, which is a lot lower than € 350, and they still make a profit on that.
@Cerberus how is "return on investment" different from "time and money"? They don't want to spend the time and money on it.... dun dun dun... because the return is too low!
@Cerberus I doubt it. I guess it's possible. I think it's just that Google has decided to focus on certain national markets first, and those ones get the phones from Google, and the rest don't (yet).
@Cerberus Well, not necessarily. e.g. Canada can import phones from the US for free.
@Cerberus Samsung's budget phones have lower costs, both design-wise and BoM-wise, than their flagship phones. Lower advertising costs, lower profit margins, etc.
what is the typical VAT in germany for phones? do you know?
@Mr.ShinyandNew安宇 Yes, but they still make a profit on a phone that costs € 80 including VAT that can do all the things any Smartphone can. I've read this in several places: transportation and tariffs really aren't a huge factor.
I'm using JSLint to go through some horrific JavaScript at work and it's returning a huge number of suggestions to replace == (two equals signs) with === (three equals signs) when doing things like comparing idSele_UNVEHtype.value.length == 0 inside of an if statement.
Is there a performance ben...
@Cerberus in JS they tried to be "helpful" by doing automatic type conversion with certain operators. So you could do 0 == "0" and it would be true. This turns out to be great for tiny, shitty programs, but awful for real programming.
@Cerberus it's awful because it's a source of major bugs and surprises. It can't be solved for reasons of backwards compatibility, unless you require real programmers to do things differently. Which is a problem because it gets rid of one of JS's advantages, which is similar syntax to other languages.
@Cerberus The problem is that in most languages with a C-like syntax (like JS uses) you compare things with ==. so 1==1 is true, and 1==2 is false, and 1 == "1" is false, because "1" is a string and strings are not the same as numbers.
Type conversion means that it's easy to screw up your comparison. You expect two things to be different, but they happen to be the same under certain circumstances.
@Cerberus It's a problem because most people who find themselves typing a C-like language use == by muscle memory. This is often an error. It leads to programming bugs when you have a value which can be null OR zero, both of which are considered the same when testing.
If var is [not] type Checks whether a variable's contents are numeric, uppercase, etc.
if var is type if var is not type Parameters var The variable name. type See the remarks below.
Remarks Supported Types:
integer True if var is non-empty and contains a purely numeric string (decimal or hexadecimal) without a decimal point. Leading and trailing spaces and tabs are allowed. The string may start with a plus or minus sign. float True if var is non-empty and contains a floating point number; that is, a purely numeric string containing a decimal point. Leading and trailing spaces and tabs a…
@Cerberus Yes, it's firstly a problem because it mimics another language improperly. But it's ALSO a problem because it exists at all; the default condition of the language is to be buggy and insecure. People who want to do things properly have to work harder (type an extra char, in this case)
Java, for example, does not do type coercion between strings and ints. or any primitive types, really. And it's really easy to write code that deals with numbers and strings and whatnot and not get confused.
@Cerberus For the same reason. If a user can control one of your inputs, they can maybe make your program do something dumb.
@Cerberus No, it is. The fact that zero, null, '0', ' ', '', false, undefined, and a few other things in Javascript are "the same" leads to many problems.
$oWpHelper->getTransient( 'worpit_login_token' ) tries to get a value from the database, or returns false if there is no value there (that's a PHP idiom... )
The point is that a user can provide something which sometimes gets turned into something else, if you by accident used the wrong operator. Most of the time, the code works, only sometimes, the code doesn't do what is intended.
If the programmer had used === or !== respectively, then the code would not have failed.
It's not convenient because == is the "default" way of expressing "equals" in dozens of languages. Only in the broken type-coercing languages do you need to use "===". But to make it worse, the "==" is NOT a syntax error, so if you forget, your code is wrong, but you probably won't find out until it breaks in production and your security is bypassed or whatever.
And it's easy to get around the problem by using === or some other way.
I have seen Matt tell people to use "var !== 1" instead of "var == 0" because some language would not autoconvert and "null" would not equal to "0" as some programmer expected.
So anyway, I'm sure it is a problem and all...but I think what Autohotkey does with %var% and "string" is a lot more confusing than this.
And a lot more problematic for intermediate users.
@Cerberus You are downplaying how irritating and unhelpful it is if your language has a feature that gives incorrect results, which uses the same syntax as what you're used to typing, and which requires you to constantly remember to do something different in order to be right, and which doesn't obviously explode in your face when you get it wrong.
The difference in syntax alone is merely annoying. The problem is that it has two syntaxes, one right, one wrong.
in some languages, variable assignment is x = y. in other languages, it's x := y.
the second example is a security bug in a server management program. It's an in-the-wild security bug, where the user can compromise the server by fiddling with HTTP headers.
That's the whole snippet. If the tokens don't match, the user isn't allowed through.
But the code fails if the user provides a token which looks like false
@Cerberus That is exactly what this code is trying to do: if the value is in the database, pass, otherwise, block. But because it uses != instead of !== it can be tricked.
Yes: type-converting operators can make some tasks easier. Especially for people who don't know what they're doing. But then they make everything else harder.
I guess you'll have to just trust me, then, when I say that programming languages which are designed to make life easy for beginners are not a good idea
I would remove features that decrease consistency, and I would remove features that surprise people. Sometimes it's hard to tell 100% if a proposed feature will do one or the other.
In Autohotkey, for example, if you do WinGetPos, it assumes you mean the active window if you don't add a parameter, but you can specify it by doing "WinGetPos, Firefox".
English Language & Usage: Multi-Layer…
English Language & Usage: Multi-Layer…