I've used lens for years and years, but don't fully grok it. Who cares? Lens is also like category theory, you don't need to understand the details in order to use it.
85 karma · joined April 14, 2014
Why not give the information to the user? There is no need to use any manual labor here.
- Logistics in Germany is awesome, and Amazon really doesn't have a leg up on the already existing logistics solutions there.
- For a cloud provider, negotiating deals now when AMD is on the rise must be perfect.
- Beating AWS on EC2 pricing is easy. AWS EC2 pricing is insanely expensive. German providers like Hetzner Cloud entered the market at 1/10th of the EC2 price.
- A k8s-focused cloud provider gets an enormous number of already existing k8s services without the need to compete directly with all the AWS services.
A "Hetzner Cloud" + K8S in Germany? I'd move all my stuff there.
If you want non-standard deductions, create a company and do normal accounting.
50-100 standard deductions can be handled centrally by the IRS with no issues. It's been done in other countries for decades.
In 2019 they will even have automatic taxation for small businesses based on the statistical average for the industry and various signals.
So basically taxation based on machine learning.
You can take it or leave it - it's up to you.
And this also shows that simpler taxation and higher taxation has no relation to each other.
You are not supposed to be able to get special privileges to your company to the detriment of your competitors.
There can be no free market when justice (and thus taxation) is not blind.
It's bleedingly obvious that it's illegal to be taxed differently than other companies. Paying back €13bn is nothing.
Companies that "make deals" on tax anywhere in the world should be effectively banned from the EU market. It's pure evil. Or pay 10x of any gain they have made anywhere in the world by "making deals" on tax, thereby undercutting fair competition in a free market.
"The Irish government agreed a deal with Apple in 1991 to only tax a certain bracket of its earnings" http://uk.businessinsider.com/how-apple-managed-to-get-its-t...
To me it's pretty obvious that Tim Cook will burn in hell :-).
It certainly IS NOT. When Apple "get's a deal" it is by definition market manipulation. You're not supposed to "get a deal" regarding taxation!
The same taxation rules must apply to every company or else there is illegal subsidy. The whole idea around "making a deal" on tax is horrendous anti-capitalist BS.
It's exactly the same as "making a deal" wrt the law in a corrupt country. A corporation "making a deal" by having government look away when they do something illegal, or getting their competitors fined on dubious charges.
Apple, Google, Microsoft, and basically all of those companies ARE THE SCUM OF THE EARTH for not refusing do to business with the market-corrupting Irish Republic.
It's deliberate to kill competition while not being in a dominant position, and then when in a dominant position, continue the trajectory by defining defaults.
The Apple apps are dominant partially because of the abusive rules the app store had earlier. It's quite clear from the fact that in any area where Apple did not have a default app, they are unable to match what the free market offers.
I cannot change the defaults in an Android phone and sell it to you. That's the problem.
Where is the problem with making Android free?
It's the other way around. EU is building credibility that seems to be lacking elsewhere by penalizing anti-competitive behavior.
The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.
I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)
The CPU will keep memory in 64-byte cache lines. There is a complex bus protocol to shuffle cache lines and subparts of cache lines to main memory.
There are additional complex protocols for cache coherence.
The cost of reading 64 bytes from memory into a cache line and when doing a write-back, storing it at a different location in main memory is zero.
Memory is always being copied into our L1 and L2 cache.
Copying data eliminates most of the cache coherence protocols that are complex and costly.
Yes we get a lot of this for free in the CPU implementation, but there is a lot of complexity that goes into imposing what is really beginning to be an unnatural model (mutable memory) on a hierarchical memory system.
FP is using a log-based model. You write to fresh memory, no aliasing, no coherence, no conflicts. You then, during GC, remap memory.
Current hardware cant "remap memory" efficiently, but it seems like the FP approach, in one form or another, is the better approach for dealing with high scalability and deep memory hierarchies: write to fresh memory, then expose a remap operation at the hardware level.
SSD disks are a bit like that internally.
There are very fundamental connections between strong typing, program verification, and proofs.
http://en.wikipedia.org/wiki/Curry-Howard_correspondence
Thus, the argument that Haskell probably has the same, is simply false.
There are large web platforms in Haskell. Yesod is probably the largest eco-system. It is clearly not as well used as RoR, but anyone can dig through large amounts of code to try to find these bugs.
What Haskell has that everyone else has are bugs/misunderstandings in how protocols are implemented. Sometimes there can be fundamental bugs in the run-time-system. However, large classes of bugs are fundamentally less likely to appear than in less safe languages.
For example, a shared library that implements SSL would have to be a shim for something living in a separate process space.
http://hackage.haskell.org/package/tls
That is a Haskell implementation of TLS. It is written in a language that has very strong guarantees about mutation, and a very powerful type system which can express complex invariants.
Yes, crypto primitives must be written in a low level language. C is not low level enough to write crypto, neither securely nor fast, so that's not an argument in its favor.
The fact that these languages don't automatically do all my system administration tasks for me is not an argument against using them.
http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...
I'd take javascript over C any day.
The parent had a good point and you should really try to look at Haskell before you say that kind of nonsense.
All the tools that are available for static analysis are basically extra type systems bolted on top of existing languages.
If you try to detect buffer overflows using static analysis of the linux kernel what you need to do is to is go through the source code and define invariants. Those invariants are TYPES in languages powerful enough to express them.
For example the invariant that memory, or any resource allocated must be freed can be expressed in Haskell.
In C++ it cannot be expressed. There are workarounds like RAII, but that does not give any guarantees.
If you do not think type systems and thus languages make any differences, you also cannot believe that formal verification makes any difference, because type systems are a weak form of formal verification. How "weak" depends on the language.
You should also read up on the Curry-Howard correspondence to learn something about the deep connections between types, programs, and proofs.