Because people (with money to spend on journalism) want a way to pay for just the articles they like.
Note that these microtransactions are where you pay a small amount of money for a small amoint of content. They aren't the burger joint model of MMO DLC where you get the buns as part of the original game, with cheese, burger, salad and condiments as microtransaction downloads.
Because people consume a lot of little things. Ads are essentially involuntary micro-payments. It's a way of aligning the interests of content-creators and with their users rather than their sponsors. What's wrong with micro-payments?
> they are generally used to extract more revenue from the existing model instead of supplant existing incomes
Blendle is doing the latter and I would only argue for micro-payments in this context.
> If your domicile had the ability to charge every time you go to the restroom, I guarantee they would just raise the rates
Going to the bathroom is something you need to do, not something you choose to do, and the friction of finding another bathroom every time you want to is quite high. Reading articles is by no means a need and free alternatives are a button tap away. You're comparing one of the most demand inelastic services with an incredibly elastic one. They will never be able to extract unfair prices because readers will simply stop reading.
So I agree that micro-payments have their place, and that place is the digital world where we consume many small things that we could do without if we thought that they were too expensive. The world that most of HN lives and breathes. But to write off micro-payments entirely is short-sighted.
As for your original question, the reason a lot of people think that micro-payments are something that people want is probably because of Jaron Lanier's book, Who Owns the Future. It's a good read.
From my (rather limited) experience, dealing with arbitrary structures in Go is a bit of a pain, as you end up having to manually create types for all of the various possible "shapes". UNlike, say, Python, where you can just return a dict or tuple of arbitrary contents.
You're both saying the same thing except you're saying "if the blinds are $1-$2 and you have $10" and he's saying "if you have 5bb". You're saying "if you have $10000" and he's saying "if you have 5000bb".
What I'm saying is that I don't see how "all possible bet sizes" leads to a game tree of 10^161. It's got to be more unless they're taking some shortcuts, such as saying that a pot size of 24xBB and 25xBB are treated as equivalent.
Also, it seems that they are only considering one stack size, where you have 100x or 200x the big blind. If the poker solver does all possible stack sizes, then it can't possibly be 10^161.
In practical play the small blind is often the basic "unit", so usually the smallest delta between successive bet sizes are the size of the small blind, or half that (e.g. at $1/$2, allowed bets might be $2, $2.50, etc)
Erlang and Elixir are both dynamically typed and do dynamic dispatch.
Erlang does not know the types flowing through a call site in advance and therefore has to do dynamic dispatch.
In particular, Erlang has a "code server" that all calls throughout the system must thunk through, versus a statically typed language where a call is optimized to a single JMP instruction. Smarter JITs, like Java's HotSpot, can also do this, and HotSpot is smart enough to inline both virtual and dynamic dispatch at runtime. BEAM can't.
Erlang's closest thing to a JIT (HiPE) cannot inline calls across modules, has no support for deoptimization, and is in effect a naive, crappy, AOT compiler which does the bare minimum to work in an otherwise dynamic environment.
Source: I made this... it was basically Elixir before Elixir:
These days I like languages that can actually avoid this overhead through the use of static typing, like Rust.
Note that it isn't necessarily bad that Erlang works this way. When it comes to Erlang's core strength: coordinating the concurrent activities of a massive number of processes/clients, it really does shine. Just don't use it for anything CPU-intensive.