zubat

An array still isn't a part of the problem domain, for most problem domains. It was introduced as part of your solution but it isn't in the same vocabulary.

A great example of transferring between problem domain language and implementation language is in game scripting. The game might have internal stuff for allocating actors and giving them various attributes, with asset references, state machines, etc. But when you go to script your behavior what you want to work with is "do this sequence of events in order, sometimes pausing, interrupting or branching it." And while you can do this by formalizing a new state machine each time, that's actually too powerful an abstraction to use to populate a script-heavy game full of one-off cutscenes, and many games will therefore go domain-specific and create a special cutscene system that limits the range of programmability.

So what I see goal oriented programming (and related ideas like model-oriented or intentional programming) arguing for is more along the lines of "principle of least power" - instead of wielding the most powerful abstractions directly, you invent a less powerful one to drive them, often compiling from less power into more power as a build step.

This is different in nature from high level abstractions intended to add more general-purpose leverage and user control over the problem definition, which garbage collection, metaprogramming, and formal-proof tools aim for.

There are many problem statements which operate on constant memory or employ a predetermined set of algorithms with known memory usage patterns, and they might employ one or more of these high level leverage tools as an intermediate to compile the definition to running code, without the user model or the runtime model needing them.

Trees are not all alike and I think this stops most such plans. Some trees have types and tags, quoting of other trees, container patterns that are representable as a tree but unpleasant to edit.

And we get stuck on that and say "Let's have a syntax." And then we're back to text again.

The boundary for transformation is established in several areas of media.

Recorded samples from the line out of a synthesizer are owned by the author of the recording, even if they're factory presets. Likewise, bitmap conversions of a vector font are the property of the game developers who made them.

In contrast, sample data copied from the ROM of a synthesizer is still under copyright, and original vector font files are owned by their authors.

That may just be misplaced energy. If you can't study but you can sit there practicing guitar or working on a hobby coding project for hours, you are certainly capable in a physical sense. But your mind cannot say "I will do my homework with identical enthusiasm to my guitar practice" and just have it happen. That is where the mythical aspect of willpower manifests and people do all sorts of things to try to make it work like that, but most people, I think, end up finding a substance to use that blunts their thinking in a particular way that helps them stay on task. That could be caffeine, or alcohol, or pot, or Adderall. Other people try to build elaborate social obligations with study groups and use of office hours. But the biggest success tends to be from getting the intrinsic motivations in place, the "I want to know what happens next" factor and those are never easy to find. Sometimes you just have to start from zero and do something very simple and low energy like washing dishes before you can access a higher level of concentration, and then quickly use that moment of concentration to make a breakthrough.

There are no norms for working from home. Hence nearly the first thing you discover is how much you respected the norms you were familiar with before and how far afield you will go before you decide to rein in your lifestyle.

The market is fluid enough - which isn't to say it's in good shape - that developers who are decent can usually find a high enough salary to stay quiet and cooperate.

Unions arise when workers have a reason not to stay quiet and they lack recourse. But in tech the response to not getting what you want tends to be to raise funds and start your own company, or at minimum freelance. This is imperfect and allows vulnerable people to slip through the cracks. But again, it's not enough to make for a turning point, at least yet.

To echo other gamedevs in this thread: Games are a lot of design powered by a little bit of code. The code can be fairly complex in instances, but the engineering isn't a primary goal. It only has to be "there" enough to support the experience.

As much as I adore all the Jay Miner-led designs, in the grand scheme of things most of the advantages they posed come from being brilliant - and highly customized - relative to their time frame. The Sharp and NEC computers marketed in Japan offer an "alternate history" look at things but even they eventually succumbed to Wintel in the 90's.

Diamond square is often swapped out for Perlin noise in terrain generators. They give very similar effects, but Perlin's method is a little more flexible along certain parameters(e.g. arbitrary offsets, zoom-in) while diamond square has more control over the nature of features at different scales, which can be used to make terrain more or less noisy.

The most concise original text is the Enchiridion. I would link but I'm on my phone now. It's a wonderful read.

I think I know what this trend is, more generally. It has to do with how explicit our code is. We've been through an era where you have some very powerful and compact indirection constructs(event callbacks, polymorphic objects, dynamic types, exceptions) in common parlance and the trend has turned against these lately. Their utility in many instances is mostly to enable technical debt, by worrying about the edge case later, and this has scared a generation of coders who have seen it go astray too often and create code that is hard to usefully refactor. And while exceptions aren't at the center of that trend, they're often implicated as a contributor.

With the new trend, you pay up front and go verbose, put more logic at the call site instead of indirecting it away. Go is at the leading edge of that: lots of LOC for boilerplate is OK in Go-land.

I'm more pragmatic with my error handing methods: I mostly care about whether I can eliminate a class of errors altogether, and secondarily what debugging implications are presented. I don't have a strong opinion on verbosity although I have followed the trend in that respect towards more call site logic.

Nobody can say! But the main thing technology is doing now is pushing us to engage design skills and critical thinking. Just "knowing ML" or "knowing blockchain" makes you a potentially useful product or service, but not a change agent. And being good enough to command the big bucks is a superstar game played per subfield and specialty. The people who are really, really into engineering work latch on to a challenging problem and can't let go - it's a pretty rare mindset and most working programmers don't actually have it, as they are there to fill seats and go to meetings and unambitiously do enough to get by. And most businesses employing them don't need a level of technology much above that either - that's why bootcamps are succeeding.

This is a world where you really need to aim to be the best in what you are doing, though. It's so competitive and there is no reason to expect that to let up. If you aren't doing that you can get stuck or hit a career deadend when the market shifts and those surface-level bootcamp skills become irrelevant.

So in my own space I am focused on a mixed stack of design, coding and leadership skills that is more in line with founders. The ability to pitch, to write up planning documents, to prototype and hold a vision, to study the marketplace and identify opportunities, to hone the vision through philosophy, as well as PM-type managerial duties. Those things are robust to changes in the technical landscape and they build on my own background.

I'm increasingly convinced that looking and thinking too deeply on people matters(news, history, organizations, relationships) is like staring at the sun. There's nothing much to see by focusing your gaze on it, it blocks out stuff more nearby, and you go blind in the process.

Which isn't to say that being a numb automaton is ideal, either, but there is a degree of balance and good taste required to avoid converting the information into dangerous thoughts, and it's simpler to restrict quantity of exposure.

I am developing a rule of thumb for this: the more pointedly in-depth your technical question is, the more likely you produce false negatives through obfuscation of intent. The grandparent's "what does this mean" question suffers particularly from being in-depth without stating it. Every CS student who learns C gets the high level treatment of pointers. But in many cases, their class does not proceed on to examine what this looks like in assembly code, except in a separate course devoted to ASM or compilers where it might be mentioned obliquely that such a representation exists. That is a relevant skill, but you have to ask for it. An easier way to get there is to ask how a C compiler turns a pointer assignment into executable binary, working backwards from the output. There are now degrees of success, since the candidate gets to discuss how compilers work if they're really engaged. But a basic answer can still capture the essence.

Very good point here The outlook of gamedevs to new tooling tends to be pessimistic because so little is actually geared towards what they work on, or want to work on.

On the other hand, Web and mobile games have lived with the consequences of a managed runtime for many years now. There are limits in how much processing power is available there, but it ultimately just diverts developer attention towards other things like a more robust backend, faster turnarounds, and other general workflow improvements independent of scene fidelity.

With respect to recorded music it tends to be the opposite: if you pitch up a track then the rhythm feels tighter and the vocals more steady, because the differences between the intent and the performance are relatively smaller. Hence an old studio trick dating at least back to the Chipmunks was to record in a lower key. Listener discrimination seems relatively less important in practice, on the other hand.

Your best bet in this situation is probably entrepreneurial, in fact, because that path lets you believe in yourself and your ideas. But you will need the inclination to follow through and that is ultimately a matter of finding the ambition and direction when your environment discourages it, to which I have no specific advice, as it just takes time and reflection. I can share a bit of my own story: graduated, took one job, then moved back home and have stayed there for six years. In that period, gradually broke down my previous self image, based on what my parents instilled, and constructed a new one that was able to reevaluate their thoughts and advice in light of my actual situation, was less taken in by "business pop culture", and would put in the effort to make the appointments and write the documents and fill out the forms without panicking.

Finally, at 30 I started to push hard and have found some kind of start a little over a year later. What tipped me over the edge was knowing that I could, in fact, run out of time to try stuff abstractly as I had been doing. I had to commit in a more concrete way to my goals or it would just get harder. And the thought of not doing it, not making things happen, terrified me much more than any of the details of actually doing it. Have not looked back since!

Agent/asset also explains related attitudes including homophobia(blurring lines between agent and asset), culturally accepted abuse(instrumental to asset control), and honor culture(no room for expression outside the agent hierarchy).

There's always something to anticipate around the corner, because the future is actively marketed to you. Oftentimes this marketing precedes the actual goods being of value - for example, VR went through a hype cycle circa 1990-1995, then disappeared for a while, because it really just wasn't doing very much yet, back then - and the headset and motion sensing tech was conflated into the onrush of CGI imagery, interactive 3D scenes, digital video, and internet technology. Most of that stuck around and consequently became ordinary. When the technology is actually the future, it becomes pervasive and ordinary very quickly. When it's a hype bubble, it crashes after a while and a bunch of companies fail.

That was the dot-com bubble: even though the internet was a big deal, pets.com and Webvan were not viable internet companies as they took on something the ecosystem wasn't ready for. They did, however, anticipate, and market to, a future where their business became viable, in the form of today's Amazon. 1990's Amazon was purely a bookseller, and perpetually viewed as sitting on a knife-edge.

Now we have a second hype cycle for VR, and while it's much better stuff this time, that doesn't mean it's actually the future. The hype around AI is similar. There was hype over previous AI techniques, too: expert systems, for example, had a period in the 80's where they were promised to do everything, assuming "everything" meant encoding a huge decision tree. Now it's the neural networks that will do "everything". NN also had a hype cycle in the 90's, but without the data and computational power, they weren't able to achieve the results we're getting today.

Developments in AI today are enumerated in achievements that become banal moments after you first hear of them: Watson beat a Jeopardy! champion. AlphaGo beat a top-level Go player. We can detect cats in images. Cars can self-drive a course better than trained race-car drivers. And so on.

It's good to be excited about the future. The marketing hype is not evil, it's necessary - it creates a dialogue, focusing people to think in terms of new technology. It's not the same as its realization, which tends to be more of a "one morning I woke up and realized I was in the future" self-reflection.

Answers to this question tend to get philosophical very quickly. The literal act of sending a message is democratized to the extent that we share protocols like English, UTF-8 or SMTP across our systems. But the social value of the message is oft contextual, creating an infinite number of spaces for socialization. You can have the same group of people in same room and yet send them on a radically different conversation by priming them to focus on something new.

Hence I think it is beyond the power of a company to monopolize the social sphere in Orwellian fashion, but monitoring, nudging, and creating an atmosphere - those things happen in any coffeehouse or bar. Small towns are known more for lack of privacy than the opposite.

In the past week I "returned" to Facebook after years of effective silence on it. The impulse was relationship-based, as many of these things are, but I had to decide on a method of engagement and decided that I was going to treat FB as a direct extension of Twitter, which I've kept up with - just tweet as usual but follow a second thread. I used to want to keep them separate to have parallel lives, but since I abandoned FB that "life" was already dead and I have learned a way of public living on Twitter that I am comfortable with.

Fortunately there is enough linkage between the two that this is straightforward. They have presented a tool that adapts to my preference, rather than an imposition or decorum. This, I think, is the direction that social software is moving towards inexorably - to separate or merge bodies, accounts, and personas as needed, across systems, according to various models of seeing the world.

I made one crucial change to my schedule which goes against a lot of the training advice I see online: only train once per week per muscle group. This usually means a split over two days and the rest is recovery.

What I lose by doing this is some of the neurological component, so I don't have those zippy gains that you get from beginner training. But I'm always completely recovered or nearly so every time I go in, and that seems make the bigger difference long term as I'm never left feeling overtrained, I can go in every week and give it 100% pretty consistently and the progress is trickling in month by month.

This is all to second: Definitely do your own experiments and focus on an all-factors outcome of building a lifestyle you are OK with. It took me something like 15 years of training to get to a point where I felt in full control of how I was going about it.

I don't have a detailed source on hand for the slaughtering operations specifically, but this is a good overview article of where the meat went:

https://priceonomics.com/when-americans-ate-horse-meat/

It's not that it won't correct, it's that the correction offers no guarantee of being humane.

In the 20th century, the population of horses (in the US) started declining rapidly, from a high of over 20 million in 1920 to under 5 million in 1960. Industry decided the horse was unnecessary after thousands of years of history, thus they were slaughtered in short order.

The only difference between me and a horse from the market's view is that I do different jobs and consume human goods. To the extent that I am necessary it is because the market will need someone to move goods and services to, but left to its own devices it might well decide to sell weapons that I get killed with. Markets are honest, not smart.

The PS1 can be characterized as "half-software" because the geometry transforms are done through a CPU coprocessor, then sent to a mostly-2D GPU capable of filling in the gaps with affine transformations. This unusual pipeline accounts for why the rendering artifacts have a system-defining character to them - information about the geometry is lost after leaving the CPU and the GPU operates at screenspace precision, making the biggest polygons onscreen the most visibly inaccurate.

Ignoring the color space is hardly a world ender for most applications, but it has an effect on quality that can be subtle to drastic depending on what you're doing. For example, arcade games emulated in MAME often have a washed-out look by default because the monitor gamma isn't included(but it can be achieved through user customization).

One thing the article misses is a process or checklist to discover your requirements for color spaces. Characterizing it as a gamma-only problem isn't entirely correct since we also have completely different models of color(e.g. LAB, HSV, YUV) that make tradeoffs for different applications. So, something like:

1. Input data: if it contains gamma data or specifies a color space use that, else assume linear sRGB.

2. Output device: is gamma correction done for you/can you access information about the device capabilities and lighting situation? This can inform viewing conditions. For example, if your smartphone has a light sensor this can be used to adjust gamma as well as backlighting to achieve a near-linear perceptual response. Most apps wouldn't consider doing this of course. If the output is a file or stream determine the most likely use cases and convert as necessary.

3. Internal processing. For each image or signal you process, determine its input color space, and the ideal color space to run it in. Then decide which approximation is an appropriate trade-off for your application(since many color space conversions are compute-intense), and implement conversions as necessary. For many situations, gamma-corrected sRGB is "good enough" hence its emphasis in the article.

You probably are in agreement. The point of putting in any time is that you have to develop an appreciation and sometimes new skills or techniques for whatever it is you're doing, before you can act on it in more than a cursory surface way. Hot takes based on textbook knowledge are easy and everyone can do those.

Recognizing that, then the problem is just one of how and when you put in that time to go in deep on ideas, when nobody is asking you to. For a lot of folks including myself, routine helps: "I will spend two hours each day on the hard thing I don't know how to solve and have no actionables on," and usually within those two hours something happens to develop your thought process.

For younger folks, deliberate engagement in "designed creativity" is something that isn't just not taught, but actively discouraged by the lack of external feedback, role models or conversations. So it's much harder than just picking up a skill by copying and subsequently making some surface changes to the copy.

Catacomb Kids might suit you. It has a lot of depth of interaction.

It would usually be a wrong tool for all of these reasons:

1. There isn't a low-level performance bottleneck within most web-dev code. It's almost all occurring at levels slightly above that(disk access, network bandwidth, database queries, horizontal scaling). The stuff that needs to eke out another 50% in an inner loop through optimizing cache access or careful use of hardware parallelism tends to be a single algorithm or batch process that can be developed independently of the larger application.

2. For eliminating whole categories of errors, there is a bounty of options out there that can claim to improve on C++ through better tools, type systems, and compiler technologies. Even Java, as maligned as it is, can constitute a credible step forward.

3. Good C++ developers aren't that common. There are plenty of junior developers who are eager and ignorant of the potential dangers, though - they will make a mess in any environment, but they'll make a bigger one when given power tools. (This is the argument for Go, and w/r to the case of low-pass-filtering junior devs it definitely makes sense.)

Although I could not speak for Islam or the communist countries, the era of the Holy Roman Empire involved a lot of this information control - the church was economically supported through unchallenged belief in its authorities. Improved access to holy texts created the foundations of the Protestant movement.

Yes. It was more common than you think to use a 30hz update, even back then - those CPUs simply couldn't do very much, and it made more intensive scenes possible. Mega Man, to name one famous example, struggles to hit 30hz at points. The arcade Double Dragon seems to manage perhaps 20hz on average.