sha90

> Wait, that can't be right, it would be ludicrous. Once a game passes the threshold it pays per-install permanently?

Yes and no. You need to meet _both_ thresholds, cumulative (lifetime) installs _and_ yearly(!) revenue. I (!)'d the yearly part there, because you still need to be pulling in a yearly $1M of revenue (I'm assuming Unity Pro here cause the math is simpler) after your 1M of installs.

So while there are some edge cases here that are legitimately ludicrous, it's not the case that you're on the hook for the game in perpetuity, because if your game falls off a cliff and you make $500k in revenue next year, you owe nothing in runtime fees. In other words, you're not incentivized to take it off the market after 1M installs unless the runtime fees made it so you started losing money on the game after your $1M of revenue-- there are some examples where this is possible but none of them are very realistic.

> The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.

This really has nothing to do with Unity. Flappy Bird could have been built on any platform and you would still have a million clones of it. Because it takes a day to make it. It's just as easy to clone that game in Unreal Engine, fwiw.

Unity didn't create the concept of the quickly built game, nor is Unity responsible for society incentivizing this type of game dev. If anything, the new runtime fees will disincentivize this type of game, so maybe that's a good thing?

How big is your team? How do you code review? How do you unit test? How are you maintaining 3 year old blueprints?

This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.

Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.

tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.

This isn't really a solid argument since stockholder investment isn't even "money"; it's collateral in the form of market valuation against which Unity borrows. The actual "money" (dollars in a bank account) comes from lenders who look at a bunch of factors and make determinations about how much $$$ to give. That money isn't free, but it's got very little to do with "the shareholders" in general.

Yes, but it has many known limitations and isn't nearly as reliable as a runtime that has a full GC and virtualization optionality, which you really need in order to fully track what state can be evicted and what needs to stay.

Keep in mind that in addition to the "learning curve" arguments, there is also the functional developer ergonomics of things like live reload (where you can maintain memory state) that are simply not possible to do with C++ without heavy limitations or customized tooling.

Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention recompiling and restarting a game can be incredibly slow.

Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.

But you need to consider that so have hosting costs-- proportionately too. Hosting data was incredibly expensive 10 years ago. If the math was working then, it should at least be pretty close to working now.

Fastmail nets around $50/year (if you pay annually) for mail + your own domain, and if you don't need the domain, it's less.

Another $50/year really isn't that big of a stretch for some people, but I can see how saving up to 70% on email would be a pretty easy choice for those who don't really care that much about email and might even use gmail if it weren't for needing a custom domain.

Can you explain what is worse about link tracking? If you're explicitly making a request to a remote service, how would you expect it to not be tracked?

Getting good signal-to-noise ratio from ANY interview, forget the big cos, is really difficult. I've seen great programmers passed over because they were _not_ given a chance to whiteboard and show their technical skill. At the end of the day, there is a bit of randomness to the process of sizing anyone up in an hour, and people will make bad calls.

That said, I'm skeptical about your particular story. As a process rule, AWS doesn't provide interview feedback, so I'm pretty sure you don't _actually_ know why you were rejected, you can only guess. Perhaps if you were rejected in phone screen(s) it can be obvious, but if you made it to an on-site, I can guarantee (based on experience being in the room during hiring decisions at AWS) that they don't almost someone because of one bad whiteboarding result; there are multiple people collecting and reporting on results and only one person, the bar raiser, has veto power, and I've never seen it used for something as banal as not writing perfect code.

I also don't know what happened in your interview, but consider it's also possible that you completely bombed it: failed to ask questions, failed to communicate properly, or made more mistakes than you even realize.

It's certainly great that you went on to do great things, but maybe at the time you interviewed you weren't yet doing those great things...

> It wasn't obvious at the time, but I think in retrospect the case can be made that Apple's ability to innovate effectively (both in terms of time and quality) died with Jobs.

Oh stop. Apple's effectiveness was entirely a product of its time. You had designers building the Zune and calling it competitive but really there was no competition for the products Apple was building for a market that was screaming for a better balance of form vs function.

This picture of Apple's innovation includes no part of OSX, which was always an OS that was technically capable but superbly messy and extremely behind on the times.

Innovate effectively? For a long time of Jobs' tenure, Cocoa was being supported on BOTH Objective-C and Java, and when they ripped it out, they actually chose Objective-C, not Java, as their platform of choice (in retrospect: wow), only to have to build yet another platform (Swift) just a few years later (Swift of course, based off of MacRuby, which they initially tried to build Cocoa on top of internally, so I hear).

Innovate maybe, but effectively no. There is a whole host of broken, abandoned, and outright bad decisionmaking in the OS layer at Apple. Apple's success has everything to do with their success with industrial design, UX design & marketing, and just a bit of being at the right place at the right time.

IMO this interpretation fits the timeline much more cleanly: Apple was churning out the same iPhones and Macbooks long before Jobs left, just as they had been before with the iPod. The butterfly switches, the thin above all else, that's all part of Apple's MO dating back years. Lack of FM radio on the iPods, lack of IR sensors on their early phones, removal of removable batteries, headphone jacks, USB-A, etc, is all part of the DNA. A $5000 screen is not surprising to anyone who saw the Powermacs of the last generation. Butterfly switches look an awful lot like bendy iPhones, which look an awful lot like DOA Powerbooks.

I'm really not sure what part of this is new post-Jobs, but I have a good feeling this is a great case study of confirmation bias. If you believe Jobs was a one-of-a-kind irreplaceable visionary who was single handedly responsible for Apple's success, then you have no choice but to interpret any action Apple makes post-visionary as a failure, otherwise you were wrong about the one-of-a-kind irreplaceable visionary.

And it would be a pretty big blow to most to be wrong about Steve Jobs.

The other interpretation, of course, is that Jobs was not a magical visionary, just a smart guy who made a couple of right decisions, got lucky on lots of others, while still getting it wrong on plenty of occasionss (Macintosh TV cough Apple TV cough Apple TV2), just like most fallible humans.

This isn't an economic issue, it's an efficiency issue.

There are 3 competing ideas: Fast, cheap, quick. You get to pick 2. We're picking cheap and quick because "fast" comes for free on a longer-term timeline. You can argue with whether or not this is the right choice, but this is the choice society is making, and IMO it would work better than taking significantly more time to build something that is only 10% faster. It's more efficient to let hardware manufacturers solve the fast problem when the differences are on the order of 5-10% a year but the time-to-release problem is on the order of 50-100% differences in development times.

This is extremely hyperbolic, and I'm sure you know this. Here's how you set a variable in React:

const foo = 1;

What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM.

What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.

Article tl;dr: "I believe that apples are more efficient than oranges after all."

I just want to point out that the idea that "modern buildings use just enough material to fulfill their function and stay safe under the given conditions" is fundamentally at odds with the author's subsequent thesis.

Modern buildings don't use "just enough material", because "just enough material" would be _just_ concrete everywhere; it would have been "just wood" 200 years ago, but that's not good enough now. This is exactly the problem: it's not software that is unnecessarily bloated, it's software that has evolved to solve higher order problems, ones that are not simply based in how fast a computer can count to 10. Similarly, the definition of "fulfill their function" in the context of buildings have changed too. That definition changes all the time, even in building codes.

In the modern-building hierarchy of needs, we are way passed the "stay safe" level. We still optimize for safety, sure, but that hardly accounts for your spray foam insulation, HVACs, builtin wireless units, complex built-in cabinetry, complex appliances, and more. Simple things like "electricity" are now part of the definition of fulfilling building function. Go find a 200 year old building and you will find a building that simply does not fulfill today's functions. Even safety standards have and continue to change all the time. You can look at historical building codes and see evolving fire safety (asbestos? NO ASBESTOS!), seismic safety, and more.

This is the point. To say that Windows 95 is 30MB discounts the years of improved process space isolation, memory protection, Spectre mitigation, that, if missing, would cause enormous public backlash about why Microsoft doesn't care about security. Windows 10 is 100x larger because WE asked for it to be. WE wanted WiFi, VPN, IPv6 switchover and tunneling all added to our network stack. WE wanted GPU enhanced UI threads. WE want haptic feedback and touchscreens and predictive text and predictive multi-touch pixel accuracy for our touchscreen laptops. This extra complexity exists because our standards changed. A text editor isn't just something that renders ASCII anymore-- heck, it's not even just for rendering characters. My "text editor" is a full web browser because I _need_ that for development these days.

Extra complexity is a feature not a bug. We built computers specifically to do this stuff, not in spite of it. The abstractions and complexities aren't getting in our way, they are literally the things we are building. Does performance suffer? Maybe, but that's because we are explicitly paying into functionality. If you wanted a fast text editor, obviously a black-and-white screen that only renders 256 characters will be faster than VS Code, go ahead and use that software, but you're not getting the other things you probably want. Your very next complaint will undoubtedly be "how do easily I diff my Git branches?" -- and this is how software becomes more complex.

Welcome to progress.