Hacker Newsnew | comments | show | ask | jobs | submit | TylerE's comments login

Couldn't that be defeated by buying small amounts from lots of different sources, melting them all down, and recasting them?

reply


Sure, but that's an industrial operation.

reply


Yeah, but doing that is easier with bitcoin.

reply


Why do startups keep thinking micropayments is a thing people want?

reply


You just read an article about them being successful, and some of the innovations they used, did you actually read it?

reply


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.

reply


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?

reply


> What's wrong with micro-payments?

Nothing inherently, its just that they are generally used to extract more revenue from the existing model instead of supplant existing incomes.

There have been several studies about decision making being taxing the brain, and always being presented with a dollar sign for any part of your experience can be a bit wearing.

If your domicile had the ability to charge every time you go to the restroom, I guarantee they would just raise the rates until you considered pooping your pants.

reply


> 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.

reply


There isn't a consumer that really wants this, but publishers don't want all you can read models. So this is what we get.

reply


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.

reply


Nope.

All that matters is the ratio of bet size to the blinds.

Basically you normalize everything into "BBs". Actual $ amounts aren't relevant.

reply


False. The strategy is different based on the size of your stack relative to the blinds.

If the blinds are $1-$2 and you have $10, you're probably going to go all-in or fold.

If you have $10000, then you can think more about trying to trap an opponent and get all their chips, instead of just trying to take the blinds.

reply


Nope.

Having a $200 stack at $1/$2 is the same having a $2000 stack at $10/$20. It's 100BB in either case, and the appropriate strategy is the same.

reply


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".

reply


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.

reply


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)

reply


To save everyone else the googling: Zimmer Frame = Walker

reply


Every phone call you've made in the last 10 years+ probably touched an erlang node at some point. That's pretty distributed.

If your're looking for more traditional server stuff, there's RabbitMQ.

reply


It depends on what you're doing.

I believe for the sort of thing typically done in these sort of languages (which usually boil down to doing lots of string processing) Elixir may well be 10x faster.

The reason?

Lack of dynamism.

Function calls in python/ruby? SLOOOOOW

Function calls in Elixir? Hella fast, because it's all resolved at compile time, there's no dynamic lookup, no creating a locals dictionary for each call, etc.

(PS: Most typical web frameworks make a LOT of function calls - all that data sanitizing, templating, and formatting has to happen somewhere)

It's true that Elixir is slower if doing numerics heavy code since it can't just call out to a highly tweaked numeric library like NumPy.

(This is all talking single threaded, of course. With a parrallizeable task you won't even be in the same zip code.)

reply


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:

http://reia-lang.org/

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.

reply


Remember that that's inluding like 60 pages of what are basically printed man pages.

reply


When K&R was written, it's not a given that the man pages for C functions already existed, is it?

reply


They were, albeit potentially more terse than is available now. System III's functions section was pretty full by 1983 even [1].

[1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/man/...

reply


System III's functions section was pretty full by 1983

K&R was published in 1978

reply


True multiprocessing is cool. Imagine never having to deal with a task queue or worry about blocking in a controller again.

reply


They do, they usually jam on several subchannels so the quality is nothing special. Plus, if the signal drops a bit you get stuttering/drop outs/desyncs, not graceful degredation.

-----


I also think the 300 kbps rate is limited if they continue to broadcast the analog signal as well.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: