vendredi 29 octobre 2021

What cryptocurrency has been teaching us should have been clear already from fiat currency, but I guess it wasn't.

When you say "money is real-world game points," that seems to trivialize money by comparing it to arbitrary rewards won in play.

What if, on the other hand, the comparison actually ennobled money?

What if realizing that currency is best created according to rules open to all players - according to strict, consistent game rules, that is - could improve the way we think about, generate, deal in, disperse, award, earn, discuss, and compete over money?

What if "money is generated according to strict rules known - or knowable - to everyone" clarified and then improved the global economy?

Until very recently, money was created behind the scenes by banks deciding to write checks to give loans.

Today, you can create your own currency that is awarded according to the rules you specify.

This is different, in that fiat currency was not ur-awarded (ok I'm playing: "minted") according to clear, programmatic rules, and it was issued as debt with interest.

The new currency is like stocks, except stocks are supposed to pay dividends. Now a company can start and instead of asking for money from investors in return for stocks, can invent its own currency to disburse according to the rules it dreams up - which must be strict and visible, not arbitrary or a matter of favoritism, and in that sense fair - and then shape public behavior with this currency. Stocks are a one-time expression, in a sense: the company issues stocks (or maybe bonds), people buy them, trade them. Crypto is so similar yet so different: the stocks issued bureaucratically, financial instruments that pay dividends, morph and become cryptocurrency that does not pay dividends and that issues according to whether you're following the rules that generate that currency. Crypto shapes the activities of the people involved directly as a reward for participation. It's like the difference between eating birthday cake once a year and training your puppy to do tricks with dog treats every day. The birthday cake isn't supposed to teach you anything, just provide calories. The dog treats are exciting because treats mean calories biologically, but what's really going on is that you're training the dog.

Helium coin is the best example of this new model I've seen. Where does Helium coin come from? You earn it by running a hotspot that helps create and maintain the Helium 5G WiFi/IoT network. In a sense you work for the company from home, and they pay you in money that they just made up, according to rules that they just made up - but, critical point, rules that are visible to everyone, and apply equally to everyone.

Voila: the concept of game points has turned into actual, investable, influential, usable money, and arguably this kind of money is better than the old kind.

Do you see what I mean? "Money is game points" doesn't trivialize money. It points out the importance of rules that we all know and that apply equally to everyone. And it suggests money can be far more democratic than we imagined.

If you ask me, this cat isn't going back into that bag. Now that anyone can create a currency, the world won't ever be quite the same.

Also, someone other than me is going to realize that game studies and money policy are intimately linked, and not just by matrix-style, Cold War-style "game theory": by the principles of game design. 

jeudi 14 octobre 2021

Lucky or skillful? There isn't much luck without skill, and vice versa.

They aren't the same, just typically enmeshed. Any skill you have, you once had the capacity for it, the opportunity to develop it, and the desire to do so: three pieces of luck.

In effect, skill is just luck that happened in the past. Perhaps it included effort. But the most incompetent person could also have been making efforts.

We understand the meaning and basic principle of evolution, yet we fail to recognize how much is random.

Most of what you define as yourself is the luck of the draw.

It's a little unsettling, I know. And we need to be careful not to let this undermine our efforts. But there it is, no worse for the wear of our feelings.
Many beginning coders have the feeling there's one right or best way to compute a piece of data they need. To simplify a bit, this is not so. Style isn't all surface: the way you tend to think and approach things, the way the language works, the way you and others remember or refresh their memory. By and large, you cannot easily tell which angle of attack will be the fastest for the machine. To be blunt, most of the time you will not know; you will guess and occasionally run spot measurements like the (other?) professionals, knowing these are only limited snapshots. When you write code, as when you write math or speak, you're constantly balancing factors, not the least of which is how clear what you're writing is to you, and by extension to others.

As coders, we like parsimony, we like clarity, we like correctness, we like maintainability (meaning best practices for the future and an invitation to other coders to fix and help), we like efficiency, we like fluency (ie, of both writing and reading), and, of course, we like both reliability in general and the power of raw cycles. Most people stick with coding because they like the ever-morphing jigsaw of inventing little gizmos and sculpting and honing and combining them. Like authors, we may enjoy the ideal of "le seul mot juste" (Gustav Flaubert's name for the single best word in context, the one you love and hate searching for), but we recognize that's partly subjective, and often a word that fits well is worth as much or perhaps even more than an ideal word, once you take into account the time and energy demands.

In short, coding, like writing the languages we speak, is both sculpting and engineering; but unlike spoken language, it's pretty easy to check the logic and run some numbers for a rough comparison of efficiency and effectiveness.

To generalize very broadly, the best way to write the chunk of code you need is the way you write it so that it's up and running. After that, improve as much as you need. I've found that in coding, the idea of a first draft is even more important and powerful than in English. There's a saying to go along with that insight, but it takes quite a bit of experience to appreciate how and why it makes sense: "Premature optimization is the root of all evil," said Don Knuth. It's inefficient and even crippling to spin your wheels trying to get code working perfectly before it's working at all. Get something working first, then iterate.

This is critical because of the nature of logic in human minds. Our craniums don't really much distinguish between a) little efficiencies that come from cutting corners, sadly introducing massive logical flaws; b) little efficiencies that preserve correctness only locally, causing problems when generalized or exapted; and c) little efficiencies that are totally correct in a wider context. Computers crash; humans don't even notice a difference. Iterate. Use the power of the compiler and empirical results. It's astonishingly more than kinda useful for some people; it's a deep principle.

I'm not saying per se don't try to get it right. Spend a few minutes—maybe a few hours on a big piece—working out your strategy, if you feel from experience that will help. But sometimes you will find an enormous benefit to giving up on getting it right, especially after those few minutes, and getting started. This seems almost too obvious to say, except it's truer in this domain than in many others for the reasons I've tried to present above, though at best I've only hinted at them.

Think of evolution: if the atmosphere needed to invent you before even getting started on life, none of us would be here today. Life proceeded, and proceeds still, by little perhaps totally blind steps, followed by a filter on results. In the case of evolution, the filter is as beautiful as what's already there: the atmosphere, the biosphere. In code, your little almost blind steps will be filtered by the compiler and the other code you're interfacing with—not to mention other humans who use it all.

I'm afraid I've written something too simple to be worth recording, but I'll hedge that bet by sharing it. It will not be equally apparent to everyone at all times.

mardi 5 octobre 2021

You know, mummification seems irrational and superstitious, but from a genetic and identity standpoint, doesn't it make perfect evolutionary sense? If mummies have recoverable DNA and we reconstruct the genome, the individual (or the family, genes overlapping) made a reproductive gamble that worked. And even reconstructing their face, their gait, etc, sends a message through time about who they were, etc. Maybe we shouldn't see mummification as bizarre and desperate so much as we see it as old, cutting-edge tech that wasn't available to everyone yet.

The oddest thing is that what would long since have been dirt is the greatest treasure in the tomb by far. Life still works through it.

(This reminds me of something I learned recently from a museum curator, that treasure was once seen as a particular material, but now we understand it's particular information. A real treasure chest contains bundles I can investigate, puzzle out, absorb, preserve, refashion, resurrect in use.)

samedi 2 octobre 2021

I don't play games for the power fantasy of being able to do whatever I want, at any time, for any reason. For that level of freedom, close your eyes and use your imagination.

No game is as powerful and free as your life and your imagination. We must accept that. It isn't a flaw. It's a fact. It's the nature of the form. When you paint on a canvas, your ideas generally go inside a frame on a flat surface. You "make life" (to steal a term from the game Go) adhere to those conditions.

A game is simply another kind of canvas. The conditions are different from those of a hemp rectangle at the museum, covered in oily pigments. But the artist—and the viewer—is constrained nevertheless. That isn't a fault. It is the meaning of art that it cannot say and do everything at once.