ceor4
Joined 10 years ago
Joined 10 years ago
Other perks include bread toasters if you're a SDE, ping-pong tables if you're in things like legal, and if you're unfortunate enough to deal with oracle there may even be snacks offered (only in a restricted area, obviously).
Your friend should negotiate very hard on salary, and perhaps even more importantly the level (assuming she's not straight from college). Most developers don't care much about titles and don't care if they're coming in as a SDE 1, 2 or 3 but Amazon makes a big deal about it. Being an SDE 1 will mean you can get shafted on everything from worse hardware specs (wtf?) and less hardware (e.g. SDE1's need to buy their own extra external monitors if they want one) and there's a lot less opportunities and discression until you get promoted which can be difficult
Perhaps the parent was trying to talk about "HM type inference" or something, but "type deduction" is also a fine name for a subset of type-inference, and perhaps more explicit for C++ and Go.
"Type inference refers to the automatic deduction of the data type of an expression in a programming language."
https://en.wikipedia.org/wiki/Type_inference
Which you'll notice C++ and Go, are listed as languages with type inference.
But you're right that they don't have as nearly as strong type inference as rust, which doesn't have as strong as haskell etc.
1) Not type checking at runtime is exactly what people mean by static typing, because the definition of static typing means the checks are done before execution.
2) This does not make it harder to optimize, on the contrary if they generated type assertions it would considerable slow things down on the boundary of typed and untyped code.
3) C++, Go, Rust, Haskell they are fully statically typed, the only difference is they support varying levels type-inference which means you don't need to "type out the type" but it's really orthogonal to the whole optional/static/dynamic typing issue.
I think apple acted pretty responsibly here.
I get what you're saying, but if Apples gets hammered with bad publicity every time their anti-fraud team does the right thing, they're going to stop doing the right thing.
Especially as this case is going to be cited for years to come, it's important apple has something to point to and say: "We didn't just arbitrarily ban the account, it was involved in manipulating our reviews"
While I'd like to give him the benefit of the doubt, the overwhelming most likely case is he was doing exactly what Apple thought he was doing. At the very least, he should take some responsibility for the fact he's paying for someones account who is actively trying to harm his competitors.
Apple probably could've avoided a lot of this mess by not overtly banning his account, but doing the except opposite of what his manipulations intended and make the app almost impossible to find.