mntmoss

I think what happened is that the developers that figuratively jumped up and down screaming about compile times all shifted towards interpreted languages.

JS has been able to do roughly what C did in the 1990's, in terms of raw performance, for some time now. The folks that need typechecking can pick up Typescript or Haxe or whatever else is attractive.

It's the bottom of the stack that really suffers - all the folks that want to work on stuff touching I/O and low level resources directly - and that is hardest to justify investing in. Unix and its baggage remain "untouchable", as these things go, and there are only some hints of promising developments otherwise.

Yesterday I did a Discord voice hangout with the folks I normally co-work with. It went off pretty well, I got to hike outside while talking to them.

It does have its limits, though. Everyone's voices get filtered through the system with the usual dropouts, zombie connections, feedback issues and equipment variations making it so that some people are heard more clearly than others.

But as a measure for connecting without physical presence it's a godsend, and a group chat can be less structured than a meeting or phone call. Set a rough starting time, let people hang out in the room, and things happen. Not the same things that happen in person, but it's enough.

The N64's RSP was quite exciting for the era because of the high degree of programmability. As it turned out, though, almost nobody did anything to program it. They used the microcode that shipped with the devkit. And since the N64 was the odd one out of the pack in other respects, it never really took off in terms of developer support.

So Nintendo's biggest lesson from the N64 was, in fact, that they needed to make boring hardware, because weird stuff wasn't going to be adopted anymore.

Sony learned the same thing almost a decade later with the PS3.

For the developers and third-party publishers, it's a really big deal to have a standard of some kind. It means that they don't have to spend their time making the market: the console makers do that, and then they just sell into it. There is always grumbling about the various overheads of consoles, but as long as it results in unique experiences that people pay for, this state of affairs probably isn't going away either.

And the differentiation of special case acceleration like what we're seeing on these architectures is less exciting on its surface than strapping a high nominal spec to some wild programming model, but it's also a more sane way of achieving next-gen performance.

Cerny's PS5 talk put it this way: The PS1's "time to triangle" (i.e. the basics of the asset pipeline are proven and real development can commence) took 1-2 months, the PS2 doubled that, the PS3 doubled that again, and everyone protested so much that they got it back down to 1-2 months for PS4, and with PS5 they are aiming for under a month, which is actually really ambitious for any development platform!

Also, I sense that the special-case approach also has neat goodies in store down the line because console devs always end up abusing hardware features to get results beyond the original requirements. There's stuff in the PS5 arch intended for DSP code, for raytracing, for decompression, and probably other things too, but most of these things are a little bit more open than just being an accelerated single-task function. I haven't seen what they're doing on the XBox end yet but I wouldn't be surprised if it has some good details to geek out over too. These functions are uniformly win-wins since they give an immediate result that accelerates something common, and then we find out what else they're good for later. Sometimes they aren't, but it's common that they surprise.

A distinctive feature of a pandemic event is that it really is a global thing. Even the world wars could claim to have quiet fronts... and that matters as a global society. Normally - since the modern era began - we're in a default state of national competition and every country is under some obligation to work itself to the bone and exploit what it can to get ahead of the others. Hence the default response to crises has long been "keep a strong international image, maintain business as usual". The crisis harms a select group somewhere and everyone else ignores it. But we did periodically have pandemics, and each one changed the character of things going forward.

And it's clear why that is the case; you can't really get ahead if you don't take care of the disease. The as-usual response fails because it affects everyone. Even AIDS, which was approached so, so reluctantly, eventually got an organized response.

And this response is more likely to be humane than most crisis management because there is so little room to evade the issue and try to fit it into the usual powermongering circus.

The "free" of it definitely made a difference, but there was also a certain lack of concern about the shape of the resulting product that made ZZT feel different and more flexible than the preceding tools when you tried to work with it.

It had built-in, non-configurable stuff for action gameplay with some puzzle elements. It did very little with regards to assets, unlike contemporaries - no animation sets or hitbox definitions or music importer or similar ideas, really just a level editor. It was just not good in terms of shelf-space bullet points - nothing flashy about it. If that was all that it had, it would not be a hugely differentiated game since the level editor concept had been around since Lode Runner.

But it also had code, and code integrated in a way that was well documented and tutorialized. It had scripted behaviors, functionality to manipulate and transform the board, and hypertext dialogues with event flag toggles. Having the hypertext and flags may have been the one most critical part of all this since it really enabled choice-based interactive storytelling techniques, and that's a huge deal even if you didn't have enough of an algorithms background to try abusing the other functionality to make a platformer or whatnot.

And so I think the longevity of ZZT really rests in the way that it guides you towards code, because it has so little else to offer.

On the upside, you have the raw story material that great biographies are made of.

In crashes all the vulnerabilities tend to collapse at once like a house of cards, and in a sense we have learned things one crash at a time. When gold was the primary form of money, there were many crashes because of lack of control over money supply. Likewise with fiat, all the crashes from indebted governments trying to print their way out and inducing hyperinflation.

In the 1929 crash there was a run on the banks because there was no confidence in their survival. The world going to a wartime economy and increasing public spending reinvigorated things but it eventually caused high inflation in the US by the 1960's - one of those factors in the country's "1970 turning" in many policies. Fear of the balance sheet getting out of control again created the strategy of huge bailouts in the latter part of the 20th century, but a downside of doing it just through lending is the "crowding out" of those actors who aren't given bailouts - which in prior recent crashes were generally individual workers, homeowners and retail investors who just took it on the chin and were told to lower their expectations.

This time is different. The attention is on individuals and their problems, and I'm seeing an uptick in discussion of UBI and benefits beyond the existing trend. There isn't faith in this crisis being solved through the existing toolset.

Computers solve the legible problems. But scheduling is one where the problems lack in hard specification, and plans involve several "layers" of prioritization, so what's called for is approximate results that avoid failure modes, which is something a skilled human does pretty well.

I do think that software speeds up some parts of the process, but like so many automated processes, it's computer assistance, not computer intelligence.

Note that this one is not a crash imposed by market forces overextending themselves(the usual dynamic of recession), so much as a reset button suddenly pushed. An economy under quarantine is not just a depressed economy, it's a different economy, as demonstrated by the abrupt mass adoption of WFH and sudden political will for sick leave. The game took a time-out and the rules changed. When we resume business as usual, it won't move the clock backwards.

So there is a silver lining in that opportunities going forward will change, but that still means "no opportunities" in the near term while everyone sorts out what to make of it.

I think the tendency of generalists is to specialize into a kind of faith in abstract principles, processes and structures that cross domains.

As kids, we mostly learn "do what we're told" because it becomes clear early on that the adults know a lot more than we do. And so by the late teens we are in some degree specialised into the ideals of the previous generation. And then we go out into the world and have to adapt. And that's a space where the specific advices we were given start failing spectacularly, but not for everyone all the time.

In this light, generalists have the quality of survivors: Facing some adversity to any particular pursuit, they aimed to lower their overall risk.

Marketing will solve this aspect of the challenge. Poverty is a relative state, not an absolute one: We want more because our betters have more. The negative associated personal outcomes of poverty are not a corrollary of insufficient carbon emission.

Therefore, market to the people climate-friendly lifestyles. Show celebrities doing their part. Make it easy to pick the right option by default with purchases. Encourage more local events and travel. It has been demonstrated that people respond to good storytelling and I don't think that is going to change.

On the other hand, the nature of "collapse" is the suddenness with which it takes place. There are all kinds of changes taking place right now, as a result of this crisis, that were previously dismissed as politically infeasible.

When the crisis is over there will definitely be some attempt to roll everything back to the "good old days", but not all of it will stick, and we'll have a different set of trends emerge - and trends in the political system may be among them. But maybe not the Electoral College. I don't see the federal system changing very quickly as a result of any current events.

The other day I spotted in the SF Chronicle a picture from the 1918 pandemic showing a gathering of people manufacturing gauze masks. [0] Gauze appears to be out of favor as a barrier material today, although I suppose one could get creative and add a paper barrier layer. There are several viable materials for the goal of mitigating transmission. At any rate, this is something open to some guided improvisation with existing supplies.

[0] https://www.google.com/amp/s/www.sfchronicle.com/oursf/amp/L...

The trends definitely favor a mobile-first approach going forward, if simply because of the additional systems integration work that goes into tuning laptops. Battery life aside, the laws of physics dictate that you're more likely to have a reliable experience with a low-power, low-heat, low-vibration machine than a screamer desktop, and those things are definitely qualities that the manufactuers optimize for in mobile devices.

It's also increasingly common to see single-board SFF desktops that are essentially laptop parts with different I/O. I suspect that those are less heavily tuned, though.

Here is what I have discovered after grinding at that process many times: You have to find a mechanism of internal feedback and drive the project through that.

What I mean there is, simply, when you get the idea and your first instinct is to seek confirmation from others, you've already erred by basing the entire thing on the whims of others. Even if you get them to become stakeholders with a substantial interest, they are still most likely operating on their whims. They go to the meeting because they are obliged to have a meeting, and the extent that they care is simply the extent that you have entangled them in it. You cannot rely on others in this regard; they can be great friends in most aspects of life and still be utterly perplexed by your ideas, even if they start seeing them working in practice. We all fly to our comfort zones. But this means that being a good student, a hard worker or a loyal friend is not sufficient to cross the threshold into realizing something original.

What you can rely on to make that crossing are tools of logic and reason: first do some philosophy and determine your thesis. Find principles, themes and references to give it structure to hang the work off of. Make sure it coheres in an explicable way, with logical premises: compare everything pair-wise, make diagrams, whatever you have to do. There are a lot of possible "systems" but having one is the important thing. You do not want to be in a position of blind faith in the idea alone, and a strong high-level concept has the power of making it easier to rationalize, explain, and argue for a certain way of doing, thus eliminating your doubts.

Once you have some starting point, generate requirements with binary true/false factors: it must have this, it cannot have that. Sketching out requirements can tell you something about the principles you have in mind so it helps to cycle between the two a bit. But you don't build a solid project just on requirements because those are so often subject to whims: "why do it that way?" "meh, felt like it." You instead challenge each requirement against the broader idea to ensure that it works at scale.

From the aggregate of binary factors, key metrics to focus on also appear. And as you do requirement generation, the motivation to do the work appears naturally because you have to do it to answer the question!

And of course, doing this, it becomes a marathon, not a sprint, because it quickly takes you out of the space where you just grab off-the-shelf solutions and slap it together. You start going well out of the comfort zone to answer your question. Now you have experiments to run and research to follow up on. The principles and themes of the project never change once established, they only become more refined and nuanced as you evaluate what the best means of achieving them are.

And I think that is, in essence, how you do it. You can achieve something resembling a successful creative work by accident, but if you stick to a principled approach your chances improve sharply.

I have been supplementing with varying amounts of D3 since 2010. That year a housemate had come down with a bad flu and I handed him 4000IU as an "anti-inflammatory". The next day he knocked on my door ecstatically and asked what that was. His symptoms had nearly disappeared.

And in the past decade, I can count only a few times when I was struck hard by cold or flu, and they were when I had let supplementation trail off. When I'm having it daily, then the typical inflammatory symptoms only appear near or past the peak of the infection, and otherwise it just presents as tiredness and scatterbrained thinking, which I have learned to notice and pay some attention to.

I currently believe that some theraputic benefit may continue up to 8000 IU or so, but this is purely guesswork on my part, having tried amounts higher and lower. What I am confident in saying, having reviewed the research recently, is that there is some clinically studied, but poorly understood positive correlation between vitamin D supplementation and regulation of cytokine production, which is crucial for surviving the symptoms of respiratory diseases of this type.

There isn't, not with this kind of stuff. Some things in life are all-or-nothings, comfortably early and overprepared or not prepared at all. In fact I would say most major life events take that pattern. Older people increasingly resemble "survivors" but they may or may not recognize the correlations here.

There are certain kinds of internal timers in games that end up locked to a base tickrate; e.g. physics behaviors. While it's possible to allow adjustment of those rates in many cases, it comes at the price of lowering reproducability and behavioral stability.

As well, it's possible to make everything smooth by adding a buffer and interpolating, but then you've added a buffer, so you have latency.

So games that specify a hard cap are usually aiming for a low-latency experience where the highest framerate is the base tickrate for the gameplay, and lower framerates are sampling from within that data.

They can identify the market but not have the right way of reaching it. Two of the biggest changes in the past few decades:

1. Everything can be shipped online, so niche targets have more options. I have a memory of craving Yoo-Hoo in college, in the mid-2000's and seeing no local outlet for it, and therefore I went on Amazon and purchased six boxes of the stuff. I got what I wanted, although by the time I was done with those six boxes, I was very much over Yoo-Hoo.

2. The move towards stocked-fridge offices as seen in every SV tech campus, which make more of these items a B2B purchase, and therefore incentivize developing and marketing products on the basis of productivity-enhancing qualities. In the not so distant past it was more common for a campus cafeteria to be relatively modest, putting things in the hands of the culture more generally...

...and there is evidence for a "big sugar" industry conspiracy in the late 20th century pinning the blame for heart disease on high-fat diets, and therefore shifting the culture for a whole generation, but primarily in North America. Other countries did not have the same kinds of trends. And since that marketing position has gradually decayed they are forced to start selling water minus the sugar, indeed they anticipated that happening when they started bringing out diet sodas in the 80's.

Yes, and the FFI friction maps to my main concern with Go as it stands: it's a bit like Python in that it wants to be extended rather than embedded. That always creates a "hollowing out" of its core over time as users exceed the capacities of its standard library and try to push it into new environments. In contrast, Lua, for example, has a parasitic quality to it: make the host more powerful and then you can easily give Lua similar powers.

However, the other half of that is that in a lot of cases, the libraries are chosen, not the language. And then why would you choose the janky "worse is better" libraries? Well, there is a reason: at some level all your code is still a prototype or draft and the "real thing" is yet to come. And then Go looks rather successful on that front in that its primitivism works at the outset and ships a lot of software, which in turn creates the demand for the heavier "big-boy" solutions.

That's a thing I often don't see addressed in this kind of rant.

That solves the problem for one computer, but I can't see how it would solve it for networks and databases, given a computing environment that will continue to evolve and foil compatibility.

But a time protocol that recieves the wide adoption of TCP/IP might suffice.

I think it helps to know of ways to model problems beyond "arrangements of objects in patterns" which is the thing that CS education has dropped the ball on the most: you get the algorithms, you get some exposure to practical systems, but then there's no checklist of approaches to try, no nmemonics to learn. Just a faint hope that slathering objects on a problem does something helpful, propped up in turn by the large body of articles and blogposts that advertise silver bullet patterns(lately dominated by "ECS", which isn't really OOP specific but fits in the usual pattern of the hype cycle).

And that is in some ways related to the consumer nature of the programming stacks in use: If there isn't a named-and-documented "feature" for it, and it's not in the hype cycle, it's a less legitimate, more hyptothetical technique.

But what are those other ways? Where's the starting place? My own WIP answer is:

* Data modelling techniques(beyond algorithmic complexity concerns: data lifecycles, persistence, schema design, and so forth)

* Formal models of finite state(decision tables, statecharts, behavior trees, and so on)

* Constraint solver techniques and their many applications(type checking, physics steps, pathfinding, depedency checking, UI automation).

* Dataflow modelling, with static routes and bounded buffers.

* DSP techniques used to do analysis and filtering of digital events at scale.

There's still an overarching tendency to let execution flow get out of hand, and our current trend for asynchronous concurrency is an antidote only in the sense that it motivates the existence of rigor by blowing up easily.

That which Lua is missing is primarily in terms of its ability to define clear, succinct algorithms. And in this respect the more Algol-derived languages enjoy a substantial advantage by having readily available tools for the task. Tables are a semantic compromise compared to list, array and map primitives, and the standard library assumes little, making it hard to write "native" Lua without encountering a need for R&D on some dependency.

But when it works in its true intended domain, gluing together and applying configuration to structured APIs and data, it's about as good as it gets, having had the benefit of major revision. And that makes it a stable computing platform, even more stable than the Lisp family(which are like BASIC in that it's quite easy to make an incompatible one). As a side effect, that also makes it an excellent source-to-source target.

But to put it another way: Everyone says they like minimalism until they try to live in it. Everyone who needs minimalism knows its limitations and makes exceptions.

It's the difference between events and artifacts, and there absolutely are differences between the two as time goes on that make even the very best preserved materials different in their essence. An event is experienced once and remembered as its artifacts; an artifact retains some substance allowing similar events to reoccur.

But on some level all artifacts are just echoes of the event and therefore are prone to decay and lose their meaning. Making it a digital artifact just allows some of those axes of decay to slow down, like an anti-aging therapy that can't treat dementia. And so it is also the case that physically realized games are more likely to play similarly in the past and present - sports have changed, Chess has changed, and both have seen reshaping via tech, but neither one unrecognizably so in the way that video games communicate phenomena with orders of magnitude more detail today versus 30 years ago.

The question, "which is better to favor, events or artifacts?" is a worthy one to ponder. Is it better to have fresh coffee available at all times, or a perfect coffee date once a month? Is it better to be able to listen to a recording 1000 times, or to attend a single live practice session?

What technology has done, beyond the basic needs aspects of Maslow's hierarchy, is let us pick and choose those options more often with fewer compromises. Its biggest failing tends to be in only solving a surface part of the issue: For example, having Facebook lets you message your friends and view their postings in some ambient fashion, without direct engagement. But it doesn't organize the party or send the invitations or prepare for guests or otherwise do the real work of a friend relationship. And so in that sense Facebook is a friend artifact that produces few useful friend events, and converts all those events that occur within its domain into proprietary artifacts of the company. But these artifacts aren't exactly worthy of emulating either. Anyone who controls them is probably sitting on blackmail.

When you refactor you are taking shots at moving around where coupling occurs. If your code is maximally decoupled it is primitive copy-paste code that never calls functions and intoduces unique variables for each section - and if it's maximally coupled it will look like swiss cheese, trying to reuse the same functionality for everything with clever parameterization, recursion, indirection and globals. Intentionally coupled code is most common in memory-starved environments since implict dependency helps reduce data overheads.

And so "DRY", to the extent that it's useful, encourages you to find slack areas in the code where there's low potential for introducing coupling, and to factor those out so that you have code that is mostly-decoupled without also being redundant and hard to modify - the factoring reflects "knowledge" about the problem. And yet it's not always obvious when you have the knowledge or not. Sometimes redundant-looking code is a form of hardcoded data and a factoring would only push it towards being fully data-driven(which exacts a price in debugging). The Rule of Three is just a common way of making this decision about knowledge.

In theory, we are asymptotically approaching a stable set of programming languages - a constellation of local-optimums. When something comes along with a different name and new syntax and cleans up some semantics, it's called a new language, but that's missing the point - the intent of the programming environment it provides remains similar. And then writing code in it is no real issue.

What ties us down to old languages is the whole environment - it is Joe Armstrong's "to give a gorilla a banana you must pick up the entire jungle" run rife through our production systems. Because our code increasingly depends on globally-sourced libraries, we tend towards copying around the entire planet and so there are layers of accretion all over.

And yet emulators do exist and run software successfully. The trick there is that they have a terrarium of sorts: a boundary that limits the ecosystem. The explosions that obsolete software tend to occur where a terrarium was not planned for by the original authors, rather continuous dependence on an evolving ecosystem was taken for granted.

A lot of the bloat is derived from overarching platform features. A 1980's application had to live on its own and communicate mostly in printed English documents. Many of those early microcomputer apps were therefore glorified printer drivers with a bit of disk or tape I/O. Everything ASCII or with a regional code page - very simple. Then we added multitasking, networking, UTF localization, variable and multi-display support, multimedia, accessibility and so on. These features add value but as you say, raise expectations - and so create subtle additional costs. We built frameworks and standard APIs to deal with each thing as it came along. The platforms got bigger, much much bigger. And the hardware profiles have shifted as well. 64-bit support adds a lot of bloat for an application that doesn't need a huge address space.

Games are often immune to these things since the final runtime is mostly "viewing" and not "editing", so their requirements are more focused, but they also get hindered by platform abstractions. Only console games can even consider taking direct control over I/O; everyone else has to go through some kind of API, even if it's the operating system's lowest level API. There's all kinds of buffering and sandboxing in consumer operating systems that is OK for media playback, but not for interactivity. Games historically act as bellwether "killer apps" - soaking up resources to deliver basically the same kinds of experiences at ever-higher fidelity, which justifies purchasing higher end gear. Then the apps follow, making use of the new install base. Things that were products gradually turn into standardized features.

There is some kind of endpoint, or perhaps reset point, to all this - when the experience is already at peak fidelity, other forms of differentiation start to set in. New apps regularly appear as the "small minimalist alternative" to a old long-in-the-tooth standard. The new kid gets bigger to cover more users. Then it becomes the old standard, and the cycle repeats. With some products this is a very long cycle - Word and Photoshop are still viable. Others come and go. But it's basically true outside of software too. Nails and screws used to be extremely valuable and difficult to manufacture, and now they are simple components - their role changed from being the product to being the feature.

I think the post is both accurate and easily ignored, because it lives from within its own wisdom. Of course you can do better if you work at it - but, why aren't you?

And that's not even a question of personal responsibility and virtue and utilitarian maximization preference. That's - what on Earth is the world doing to discourage you, to make you grind at Overwatch in an ineffective way, then try to compete without appropriate prep? How did your ego get into such a fragile state that asking questions and getting advice feels so difficult?

And with at least some of these questions, the answer is that the intent of the person is different from a genuine competitor in a way that keeps them in a state of self-sabotage. They may be turning to the game as a way of gambling for a dopamine rush, in which case they can't believe in their skill(or anyone else's) - since they want fate to do the work.

But then you probe further and it gets more nuanced. Many people have trauma getting in the way, a whole bunch of stereotypes and expectations beat into them from an early age, which prevent them from reaching out and grasping at the prize. Many are trying not to get too deep into their hobby, because they have a lot of other stuff going on. And so on.

And so the question of why there is a 95% is related to our tendencies around resource allocation as a society and what skills and beliefs go along with that, which creates preferences, which then acts to enable or limit people.

It's never quite as simple as "you could just practice." Finding the way in which practice works for you, lets you set goals you can agree with - that's the trick.

You can use empty scope braces for this task in most languages. It's not a "half-indent" but it gives you the alignment and informs responsible variable usage.