mntmoss

The way in which Sega ultimately approached its console hardware business was actually similar from start to finish; you just have to look at the pre-Mega Drive consoles to see that the Mega Drive itself was the shining exception within a strategy that was very "spray and pray".

First there was the SG-1000 and the SC-3000 computer in 1983. Then there was a mostly cosmetic update, the SG-1000 II. Then there was the Sega Mark III and Master System; the Mark III had a variant release with an FM sound chip. All of these releases happened within a span of four years, 1983-1987. Throughout these releases there was a heavy focus on arcade ports, and Sega struggled with marketing the console as its own kind of experience.

When the Mega Drive came out in 1988 it was a big enough leap to be a stable target for a few years, and then Sega reverted to their previous ways. To the extent that Sega "got" their console business, it was a case of a few teams in various departments and subsidiaries that bucked the trends.

I think it helps to consider this a problem of "slow vs fast".

Society has displayed ways of sheltering and hibernating through tulmultuous times and subsequently developing some kind of response.

Chief among this is the reuse of the old. Of course you can build new quickly; that's what Andreesen calls for. And it's easy, as these things go: Hand some money and labor to someone who wants to bark orders and throw their weight around and they'll get a thing made, like Ozymandias building his monument. History always provides such people.

But reusing old successfully is the thing you need crafty witches and wizards for, and they usually only reveal themselves when a dragon shows up and needs a talking-to.

In this case, the dragon is that tendency to push information towards a model of legibility by the state and for the populace to in turn aim to be inscrutable, a back and forth that has occurred throughout history. Sometimes this shapes spatial life, as with the story of medieval taxation based on the number of windows in the house. At other times it uses political theory and precedent to assert rights. Here we have the opportunity to be inscrutable by a rather direct escape from the norm, simply using some less popular alternative.

This is a crisis mostly in the sense that we still crave to have a popular, inclusive, fast-moving discussion while being inscrutable to power, and you can't square that circle so easily. Rather, you have to look towards gradual redefinitions of reality and possibility to counter normalization. This is necessarily a slower process than simple surveillance and seizure.

With respect to the Web, it's clear enough that it was built with holes in it, and much of the resulting stack was further distorted in turn. Why? Because it was a new thing - and evolved defenses as it went along.

But now it is an old thing, and as a popularizer of concept has succeeded wildly. The concept is what we'll probably use, and the specific tech only in parts.

What ad-hoc code generation lacks, as a rule, is type constraints and structured expression(syntax and semantics). If it has those, it is bordering on being a complete compiler.

But if your base environment doesn't have notions of types or structured expressions either, which is mostly true of assemblers, then you are free to use macros to program at a higher level. The expressive power you gain by leveraging macros doesn't have a real downside because the core language is already so limited that it won't be more legible or maintainable to do it by hand.

I'm pretty sure there's room for smaller verticals these days. It's been demonstrated many times that if you have the best front-end to the problem space, and you add some services on top, everything under it can be totally commodified but you'll still get customers.

From there the strategy would depend on whether you want to stay small or not: To get bigger, you'd start going deeper into the open stack to scale things up and provide a wider array of services. If you stay small, your organization will necessarily be more focused on interfaces and compatibility while maintaining that top-end UX. In both instances there are plays for open source, but with different characters; the big company will tend to code-dump an enterprise toolchain, the small one will primarily be a contributor to a foundation project or open some of their internal interfaces.

I'm getting to 35 now and I had an experience that felt very similar to yours in my coastal magnet school. Lots of academics, lots of extracurricular stress, kids of immigrants who pushed for more, more, more. The guy who sat next to me in German committed suicide.

As the years have gone by I've realized two things:

1. The other behaviors are there, but they get filtered and harder to notice. Many of the situations you see in dramas are just...less dramatic, and more ordinary in real life. People don't want to bring it up, they want to stay in their routine, and when you have a ton of structure(as is the case in these schools) things move on too quickly to reflect on anything or become self-directed, so it gets repressed. The media version goes out of its way to highlight it, in contrast.

Many years after I graduated, the popular physics teacher at my high school was caught fooling around with the girls and doing favors for them. Apparently this had been going on for many years. You never would have known. He was a good teacher.

2. At a young age, even if you've encountered these things, you aren't necessarily sensitive enough to accurately judge what is happening to you or to others. Since teenagers struggle with this they start looking for easy ways to provide themselves with an identity - and media is happy to supply you with a stock identity that is, in rough approximation, true to you. But of course, they are all a mismatch on some level. And when young people socialize they are often prone to projecting on each other in an unhealthy way, drawing boundaries and defining characters out of thin air.

Which, if I were to turn that into advice, it would be: Stay focused on the ordinary stuff. Keep a diary so that when you notice something, it gets recorded and you can reflect on it and challenge it. It's the one thing that is most missing when you get caught up in feelings of urgency.

Yes, this argument is one shared with some arguments for minimum wage. When a sector of the economy can set wage freely, it often races to the bottom on price competitiveness, neglecting automation and training improvements; businesses that attempt to raise their quality get pummelled by the higher costs and risks relative to competition. A rising minimum wage standard therefore encourages modernization of the work environment.

With UBI a similar effect is had on the demand side: If you assume a higher base of income, then consumer credit, payday loans, friends-and-family-favors, etc. become less of a necessity for low-income workers. Higher-income workers with long-term debts like mortgages and student loans become free of their debt more quickly, and face fewer consequences if their income takes a hit. The workforce is therefore disentangled from a set of predatory financial interests that chain them to needing their current job and to stay in the good graces of their financial backers. Even a very small amount of UBI will create a substantial reduction in poverty traps, domestic abuse, and labor mistreatment.

What tends to be absent in the simple analysis that leads to these kinds of hammer-to-all-nails solutions is a full enumeration of the classes of errors or intractable problems in the domain, and how the proposal does or does not address each.

This blogpost does not even attempt such an enumeration, but instead appeals to aesthetics.

FWIW I went through a period of using map and filter a little bit, went, "that's nice", and then resumed using for loops, sometimes with comprehension syntax to sugar it up. Both methods basically cover ways to specify simple iteration and selection. But I know which one is going to port better across the majority of environents: the plain for-next, and if a complex iteration is called for, the while loop. It puts the data allocation where I can see it, and it maps to the single-threaded computing model that is still the default today.

If I want a more complex query, I am going to start wanting a more expressive query language than either imperative or functional selection and iteration can provide by themselves. Left outer joins do not come easily to either method. Neither does constraint logic programming. You obviously can implement those things, but it isn't blindingly obvious, and when your problem grows to need a very broad expression of selection and iteration, it is those kinds of tools that you really need to aim for.

Some time ago I realized, while standing in the midst of the Oakland Museum of Art and Digital Entertainment, surrounded by old game boxes, this:

"Most of these games are all marketing."

That is, if you look at the art, and look at the back of the box bullet points, you'll see something like "Go on an epic journey", or "Choose who lives or dies", or "Build an empire to stand the test of time".

To the extent that these games express these things, it's through clever rearrangements of stock tropes: Your typical murderering and looting game protagonist, able only to communicate down the barrel of a gun, is now justified through the plot and given many new backdrops so as to make the journey "epic". A scripted choice is added here and there, but not everywhere, to make "choosing who lives or dies" feel consequential, but without ascribing particular meaning to the choice either(since all choices should be gratifying for marketing purposes). Empire-building is signalled through various reports of legible progress in gaining territory and developing cities and armies, but nothing resembling the actual political structure or dynamics of an empire - the fantasy is simply one of a "rise and further rise".

And so in playing these games, you get an aesthetic impression, but not something with a solid grounding to it that you would spend time thinking about afterwards or relating to your real-world experiences. When a speedrunner sets out to conquer these sorts of games they look for software vulnerabilities that short-circuit the impression of what is going on and attack the underlying data model and logic.

In that way, video games have been pushed through industrialized practice quite a ways away from the natural state of games as a tradition, which is to fully and honestly explore simple concepts. You can't speedrun basketball, because you're playing within the laws of nature and against opponents who do the same. But if you go to market a basketball video game, you are trading on the impression of basketball, not its reality: and so licenses for professional players, superlative simulation techniques, etc. come to the fore.

So as I see it, games like Candy Crush are further extensions of industrialization: The game concept is simply a tool for the marketing framework, which in this case has been designed towards metrics-optimized microtransactions and customer retention. If a particular level is failing to retain players or to induce a purchase, it gets reworked until the metrics line up.

Despite all this, good work in games does tend to shine through. Nintendo's franchises, for example, are all built on "honest explorations" of their basic themes, and the play concepts tend to have something intrinsically interesting going on. And the breakthrough indie hits usually have this quality, too. The games that get buried, in contrast, usually aren't achieving the same degree of cohesiveness and direction - even if they're huge AAA productions.

The distinction is in quantity and types of assets. In 2D you usually have some bitmap and vector assets, collision data, animations, and scene structures to tie it all together. In 3D you have all of those things plus the texture/model/material distinctions, lights, skybox, and all the other details that come in as you add more rendering capabilities.

However, you can absolutely make 2D games that need lots of kinds of assets. RPGs happen to be one of them, in fact: The incidental details of adding inventory, NPCs, abilities, dialogue, etc. does add up. Every little message and description, every item's properties. You can ship a game by hardcoding much of it, but that's not going to scale with any substantial team. You need real data management, build processes, etc. Where assets interact with each other you get incidental complexity of the Dwarf Fortress bug kind, so where you can, you add static checks. The engine is built in tandem with the asset pipeline, in effect.

So - whether it's 2D or 3D, what actually matters is the assets. That's why even in the early 80's you had vector games with 3D effects in them; they just took approaches that simplified the assets and the resulting scenes.

Definitions of games are quite prolific.

In academia many end up going back to Huizinga's "magic circle" [0] which he was writing about in the 1930's, before any video games were around(although many immediate mechanical precessors were in evidence like pinball and slot machines).

From the perspective of a game creator or player, what tends to be of primary importance is the information conveyed through the game, which can be primarily aesthetic(a pretty picture) or deal with specific themes and principles. In this light, introducing the magic circle is of some importance because of its clarifying property: the information is exploring these concepts, and not some others that you might be interested in.

And so it goes with many opinions about games, too: if it doesn't cover the topics they want in they way they like, players reject the game. Some players need to see violence and power struggle, others need cozy reassurance.

[0] https://en.m.wikipedia.org/wiki/Magic_circle_(virtual_worlds...

I don't disagree. I believe, though, that our working philosophy limits us: "pursuit of property" in the Lockean sense, and "pursuit of utility" in the Bentham-Mill sense have guided a lot of what we currently build and define the right-centrist consensus. Marxist-anarchist answers are often unsatisfying in that rejecting the market as the benchmark tends to lead towards bureaucratic or tyranny-of-structurelessness outcomes where gatekeeping and favoritism thrive, because, as Confucius says, "the most important thing is to define words" - change the words, change the benchmarks and metrics, and you have set the agenda for society. And if you let people tinker with those benchmarks at random, you get random results, skewed to optimize towards a fairy tale. Think of all the fads and trends you've seen in your career - serious proposals for improving your skills, productivity, status, income, etc. How many of them ultimately ended up being a disproven hypothesis built by someone doing some brand-building? The market weakly indicates demand, but it's a naive system, prone to acting like a toddler.

This is, in fact, often a major question in game design too. When the problem space gets reduced to a score optimization problem(whether score in the context is "high score" or "maximizing some form of output" like HP damage), you often end up with degenerate solutions that involve a repetitive linear application of some technique. And when this appears in a competitive context, the game starts stagnating into a rote exercise of min-max, and other solution sets go unexplored. Competitive players often look for ways to gatekeep and declare a playstyle unacceptable so that they stay in their comfort zone and keep their status - but acceptability is ultimately a matter of what you believe the competition is or should be about. If you don't have that agreement of shared belief, the game itself falls into incoherence, and that is what we see at a broader scale in society where its systems fail.

But there are some answers. One is to enforce a broad set of all-or-nothing contractual failure modes: If you fail the minimums you don't get the maximum. At a baseline we have Maslow's hierarchy of needs setting some of these minimums. And our legal system often works in this direction of adding a minimum. Another is to add buffers, delays and noise on results: If you don't have an instant guaranteed outcome, you can't push your margins nearly as hard, and so you don't end up in a distorted min-maxing zone, but a more systematic one, which can only be manipulated through careful synchronization that "gets ahead of" or "applies leverage" to the problem. This is something we're now dealing with increasingly in an interconnected "instant society" where continuous access is the norm and many activities that were one arduous and needed a strong commitment have been reduced and repackaged into status symbols. Lastly, overt market mechanisms - pricing and bidding and ownership - help when applied appropriately. But they are premised on active participation in the process, humans in the loop who can really think through all the factors. When we automate market activities, we end up back in the scenario of min-maxing.

Lots of fun things to think about. It's not just the building that matters, but the "why" of it. If you can justify the "why" you can get a lot farther.

IME it's all down to the implementation these days, which is a low-bidder-gets-what-they-pay-for kind of affair. My phone is cheap and the Bluetooth is nearly unusable on it(it can only really support one device at a time and that device will periodically drop out), but on my laptops, which have more of an emphasis on build quality, it's pretty solid, with few to occasional instances of audio tearing.

Regardless I still find grief from things like the volume resetting on one or both ends after pairing. There is a lot of attention to detail needed to get this stuff right, and most companies can barely manage to ship - that's not on the standard of the spec but the standard of the marketplace.

In two parts:

1. Fix the underlying ergonomics. Put your monitor higher and your keyboard closer. The position you want is like the rest position of a dancer: elbows nearly against your sides, relaxed. (Taking an actual dance class will teach a lot about posture habits). A small change of a few degrees here and there can make a big difference. If you are a laptop user and have been actually resting it on your lap, try putting a shoebox or similarly sized object under it.

2. Train mobility. The hunch develops as a result of persistent overtraining in one direction. You don't need a lot of additional strength to start to correct this, just mobility.

Look up Youtube channel "Calisthenic Movement" - there are some very good mobility routines and I have incorporated parts of them into my everyday workout. Some of them use a pull-up bar but most are pure bodyweight and the floor or a wall.

If you want to stock a home gym I suggest going for resistance bands - they're small, light, cheap, more forgiving than weights and hugely versatile.

1. Write placeholder output, the equivalent of a Hello World for the task.

2. Start parameterizing parts of the program to generate the output, so that more and more of the output comes from a few source variables.

3. Eventually you want a user interface on this and have it load from disk instead of recompiling...and so you end up with a complete program.

You generally don't get there just by concentrating really hard on the architecture. You architect a bit and then try things to get empiric feedback.

For most programming tasks I would focus on the base of the pyramid: Make the storage low-latency for small files, then up the memory size and bandwidth, and then use a CPU appropriate to the workload(ideally, it can go wide and parallelize - otherwise you're back to single-threaded perf). This mitigates the worst case of poorly optimized builds that need to frequently return to storage, and it improves all factors of the operating system when it chooses to swap to virtual memory(Windows has become a very aggressive swapper since Win10 launched and they added a new page file system on top of the old virtual memory).

You can spend time gazing at the benchmarks for each CPU, but I would not pinpoint it as the bottleneck for a responsive and pleasant programming environment. The new AMD chips are good all around. The new Intels are still OK, but the top end probably too hot and loud to reccommend.

For gaming, high clocks/high single-threaded IPC remain the primary factors. Games are mostly designed towards a certain number of cores and speed of I/O. Fast disk and memory will reduce sources of stutter but this is dependent on how often the game tries to load something.

What I think Cook misses that Jobs got, and made for more exciting releases, is the idea of a totally integrated service. The iPod's victory was also a victory for iTunes. The iPhone was also the App Store. And when Jobs left, those kinds of distinct pairings did too. They are hard to concieve of, and to execute on.

In contrast, the AirPods and Apple Watch are more straightforward "make 'em smaller" incremental moves. The engineering work is leading in many respects, but it doesn't upend a market.

And Intel does have a history that was like Apple's in parts. A big part of their advantage as the PC market heated up was in marketing an entire nomenclature of what the platform could be and to provide comprehensive path-of-least-resistance solutions around that, ensuring that the industry fell in line around their technical lead rather than IBM or some competitor.

Those bones are still there in parts of the company - Intel chipsets are pretty well regarded for dependability(seeing Windows crash because of Intel drivers is a very rare event) and they've been good at getting the corporate office to standardize on them - but increasingly the platform is getting defined around mobile and server needs, which are a more competitive space generally. Intel doesn't get to call the shots on 5G, for example - and huge data center customers are in the business of optimizing the system end-to-end to provide the most efficient general computing resource possible; everything they touch commoditizes, and they will put their foot down if they smell enterprise contract crap.

The question to reconcile in my mind: Malleable systems with reproducable builds.

It's very easy to get your hands dirty with the bytes and add various assumptions and dependencies. Most "hack solutions" go in that direction. But reproducing the modification in some larger context changes the assumption: What if the dependency isn't there?

What tends to make the system stable over the long term is the thematic assumptions: Certain broad goals that never shift, even as the specification does. I think that's the factor missing from having malleability itself as a goal. You already have it, that's software.

Money is intrinsically related to debt and ability to pay one's debts. This has several meanings when you look at different scales of money.

An individual's debts are related to near-term life needs: making rent, putting food on the table, paying bills, paying for an education, and paying to assist friends and loved ones with each of those same things.

A local government has to use taxation and debt to take on major infrastructure projects and provide ongoing public services. The money represents some mix of the will of the taxpayers and creditors, plus any private interests brought on to finance a project.

At an international level, money represents the trade and economic competitiveness of the nation and is a mode of diplomatic influence and trust in the nation's stability and internal control. A country that wishes to import more goods will seek a stronger currency; one that wishes to pay off debts will probably inflate their way out. The spending of the nation is reflective of the size of the government relative to the private market, and so high public spending may "crowd out" private, but it can also bolster markets by giving them confidence in demand for goods or availability of labor.

And at each scale you can make cases for earmarking some things, pushing them up or down a level, or letting them be resolved through a general fund. That's the incentivization that drives the specifics of an economy. Most countries now agree that fire protection should be financed as a public good, for example, rather than having each resident contract for fire services. But with health care there is disagreement, with employment benefits there are disagreements, with education there are disagreements and so on.

Basically, UBI is a statement that some amount of the public trust should be redistributed as money rather than as a specific good. This puts a lot of flexibility into the hands of the taxpayer. The arguments against whether UBI at all tend to be either "save the little people from themselves" (while wealthy investors get a pass), or "we cannot afford it" (while larger organizations are bailed out on the regular) - and topics at this scale get entangled with national character too.

If in the USA one would ultimately want to evaluate the idea of UBI according to the Constitutional Framers' "life, liberty, and pursuit of happiness." Life - yes. Pursuit of happiness - yes. Liberty - up to interpretation, given the "money is debt" premise. In another country other principles would structure the test.

It's a fine line. There are plenty of stories of games that dumbed down their AI because it started doing inscrutable things when fully unleashed - and simulating full sense perception for something like a soldier in a shooter game is very computationally expensive, so "smart" opponents tend to feel like cheaters since they are thinking in terms of the underlying representations instead of behaving or reacting in a believable way.

A lot of making the experience of a game is in managing perception and belief - in making the player agree that the game is doing "what I expected" - and when a feeling of realism is aimed for, the amount of falsified behavior needed to get that result goes up dramatically. The games where belief is easy to achieve are mostly stuff where the ruleset is abstracted, empirically tested and legible to all - board games, physics games, puzzle games, etc. Things where the decision making itself is the intelligence. In contrast making soldiers that are satisfying opponents requires a blend of assets: carefully managing their positioning, animation states and voice callouts so that their decision making is something that players can identify, respond to and overcome.

"Factoring" is sometimes used in the Forth world, since code being factored into small words is of such eminence.

And it offers good lessons about what's worth factoring and how. Forth words that are just static answers and aliases are OK! They're lightweight, and the type signatures are informal anyway. "Doing Forth" means writing it to exactly the spec and not generalizing, so there's a kind of match of expectations of the environment to its most devoted users.

On the other hand, in most modern environments the implied goal is to generalize and piling on function arguments to do so is the common weapon of choice, even when it's of questionable value.

Lately I've cottoned on to CUE as a configuration language and the beauty of it lies in how generalization is achieved while resorting to a minimum of explicit branches and checks, instead doing so through defining the data specification around pattern matching and relying on a solver to find logical incoherencies.

I believe that is really the way forward for a lot of domains: Get away from defining the implementation as your starting point, define things instead in a system with provable qualities, and a lot of possibilities open up.

The real beauty of Nintendo's strategies, I think, is that they validate many forms of analysis.

The design in them is never just great hardware, or great software, or great marketing, or any one objective quality metric, but some kind of blend of these things that defines the problem they are solving such that they avoid risking catastrophic failure in any one of them.

And this strategy whiffs on occasion, but it generally does so in a recoverable way: Wii U underperformed, but that meant that they didn't have to shepherd along the base with backwards compatibility. The biggest titles on it instead got ports or sequels on Switch. Nintendo never sells consoles at cost, so they lost development money but still came out of the endeavor with a refreshed game library. It's very much a "fast is smooth, smooth is slow" kind of notion.

And this is something you rarely see elsewhere in the tech world: The focus there is not just on making a gadget, but a world-beating gadget that boasts unsurpassed specs and rushes to beat the competition in doing so in the "move fast and break things" fashion. That approach leaves these companies with no room to build a legacy of the type Nintendo has, because their ambition was to skim some cream off the market, and maybe attain platform lock-in for a time, but not to really curate their own work or become something people refer to over the long term. And this is even true of most of the other game publishers, too: They burn through their franchises with casual abandon and trust heavily in their sales and marketing organization to make up the difference.

The military - and many essential services like police, fire, healthcare - differ in that a majority of the work is not "doing" but "preparing". The military does not optimize towards cheaply increasing daily metrics of death and destruction, rather, it aims to use a targeted amount of force to achieve a particular national objective at the exact moment demand for that objective arises. Most units sit idle most of the time, in a runtime system with very low latency and variable throughput. The same analogy is obvious when you think of police(we don't want crimes committed), fire(we don't want lots of fires to fight), healthcare(we don't want tons of patients).

And that leads towards the extensive investments in training, doctrine, equipment, logistics etc. And so the majority of military employees are not "doing work" in the sense that a tech startup is, where every employee is directly engaged in optimizing the system's value chain - that kind of work occurs only in the core command, around the generals and planners and architects and researchers of the next war. The majority of the work is simply maintenance of the system so that the needed response is possible when called for.

And I believe this examined difference in organizational purpose also applies across a lot of businesses. The value chain is always shifting in surprising ways, but generally in the direction of lower maintenance.

Whether it works or not depends on how much your relationship is built on systematic, empirical decisions. Spreadsheets like this are hugely common in larger communal living arrangements.

And there is a harsh quality to it, but I don't think the people knocking this strategy fully appreciate the danger of a relationship built on illusions or delusions. If you come to me saying "true love overcomes all" or somesuch I'd be seriously concerned about gaslighting or codependency taking hold.

You may want to try raylib. It's written by a teacher who uses it in the classroom and geared for this kind of "let me code games in C but with only one dependency" goal. It does more than you need but that's a common theme of useful libraries.

I don't collect things I "need to get to", if that makes sense. I collect things I'm willing to spend time curating, which generally means they go in a file somewhere under a directory called "References". References means music I like and art I want to study and writing I want to return to. If I want to have a log of what I was interested in, I privately journal about it(Which I am happily using Penzu[1] for).

The trick to all personal information management, which recurringly appears in HN threads on the topic, is to focus on your filters, not your collection. You collect hastily, in anger; you are not a professional archivist with respect to your own collection. You will misspell and missort. But it is easy to punch "Save As" and get it in a file somewhere with a few words to search by. And so the filter, the post-hoc, is the greater necessity.

Fortunately, when it's in the form of files, you can apply a mix of hierarchy, tag and search methods. There's software for this. I currently use TagSpaces[0]. I don't spend a great deal of effort manually tagging, I just organize a little bit of hierarchy and throw some keywords in the filename.

As well, I expect to lose a little bit of the paper trail at times. Precise origins and authorship are not always accessible. Redundancies may occur. The point of the curation is to make a useful product for yourself, one that accommodates many informational needs - to collect ideas, create a course of study, or put yourself in a particular mindspace. You have many years to keep developing it.

[0] https://www.tagspaces.org/

[1] https://penzu.com/ (Why this and not plaintext? It has an app, and it auto-syncs.)

Foley mixing is still the state of the art in the majority of cases, but there is a lot more DSP power to throw at spatial positioning and acoustics, which makes the resulting mix a lot smoother.

It's the Rule of Least Power in action. [0] You don't want to have extreme degrees of polymorphism the vast majority of the time.

[0] https://en.m.wikipedia.org/wiki/Rule_of_least_power

Some of the biggest early Haxe users like Tivo were explicitly looking for a vehicle to transition off of Flash. That part of it definitely makes sense.

But more generally it is incapable of the kind of end-user tooling that attracts early adopters. This is because it targets everything, and so really using it means knowing the platform you target and being able to debug at both levels - it does what you would expect a best-effort compiler to do, but it does not try to magically cover up what's going on. You can be put at sea pretty quickly if things break several layers down.

And that makes Haxe a great technology and a less great product. When it's paired with a framework like OpenFL it seems to get a lot of interest though. I see it as a long-term "survivor language" since its premise is still valid - it will be able to keep hanging on, gradually accumulating more of a basis for itself.

In the end they're all situational formalisms. Imperative code is by definition implementing a state machine.

One thing that you can often get by moving the state machine a bit away from the source code as tends to be the case with these libraries is a definition that specifies I/O more concretely. In something like the Unity3D Tick() case, I/O is open-ended: All game state is available, and that state may itself impact when Tick() is called via various concerns of concurrency(timing, update order, etc.). When trying to apply a formal model it's usually a really bad sign to see a very broad "tick" or "update" callback dumped into execution - it leads towards hacky code that sets flags and uses frame boundaries to confirm events.

Game engines don't always have the best examples of these patterns, since games can so often get away with shoddy usage.

In all markets, and generally as a life strategy, there is a "winner" method and a "survivor" method.

If you play to win, you are most likely following accepted best practices to maximize gains - in your career, socially, economically, and so on. You optimize to "cut the fat" regularly, stay with the trends and try to be the front-runner in everything. In this market, playing only as a winner amounts to taking on huge amounts of risk, because there's high volatility and little accepted wisdom or trends to follow. Any move that uses leverage could be the one that makes you wash out - and in the same way, being gregariously social to keep up appearances during a pandemic may kill you.

The "survivor" method is what it sounds like: playing to not lose. They are not just aiming for low numeric risk factors, though; the point is to have second, third etc. lines of defenses against black swans. Survivors will tend to look for overlooked niches and early diversification. They amass unlikely hoards while keeping their heads down, which leaves them isolated a lot of the time.

In general the optimal position for every market is where winner strategies intersect with survivor strategies: Find something that is relatively stable that nobody is talking about and move your money closer to it. Then when the business cycle picks up your portfolio magically turns into something positioned to capitalize.

Of course, the essential problem is that if nobody is talking about it, how are you going to discover it? If you wait until it hits the news, that's probably too late.

But business formation or repurposing presents another option. Down cycles are opportunities to start the next trend yourself, because the air is clear and you don't have heavy competition. When a market is competitive, everyone spends on sales and marketing to be the loudest voice. When it's quiet, "build it and they will come" becomes a great deal more plausible and you can really focus on product.