Game dev in general is that way, but my impression was that Colossal Order had traditionally been a little better than most. I suppose I may have been mistaken.
Using web tech for the UI isn't a problem here. The article, when measuring the performance impact of different rendering phases, describes the time the UI requires as "an irrelevant amount of time."
I disagree that it's actually redundant. It's like if back in 2004 somebody said "Apple computers are overpriced and underpowered." Technically, "Apple" in that sentence stands for "Apple Computer," so you're saying "Apple Computer computers are overpriced and underpowered." But that's fine, because it's just part of the company's name, not actually a redundancy. No copy editor would have flagged that, but they would have flagged attempts to remove the redundancy by saying things like "Apples" or "Apple Computers." Similarly, Fish is a name, so adding "shell" is useful in identifying the thing you're naming.
Game companies do take a similar approach to what you're describing, but still feel the need to run anticheat. If you ban aimbots based purely on statistics, you'll just encourage cheat developers to change the statistical properties of their aimbots. Cheats are a fairly big business — even detecting them with anticheat software in ring 0 doesn't seem to be a surefire guard against cheating.
The benefit of a website like Patreon is reducing friction for small transactions like this. If you're going to put in lots of time and effort to convince one person to give you a million dollars, you can probably get them to write you a check more easily than you could get them to pay through Patreon But For Whales.
There's a big difference between the data structures, yes, but the basic logic for message sends is still pretty similar. They both boil down to a simple lookup in a data structure and a jump. Would you really characterize the difference between a vtable and a hash table as "you actually pass a message, that first must be interpreted" in the case of a hash table?
I think putting it that way exaggerates the differences a bit. The message doesn't really have to be "interpreted" in any meaningful way AFAIK. A message consists of a selector (essentially a method name) and a receiver, then whatever other arguments the method will take. The runtime looks up the selector in the receiver's method table, much like with C++ virtual methods, and then jumps to the implementation it finds. There is a little more fanciness (some method caching, and support for nil receivers), but I don't feel like it's hugely dissimilar from virtual methods.
For anyone who isn't familiar, Aaron is one of the most venerable Objective-C programmers out there. He worked at NeXT in the '90s and has been teaching new Objective-C programmers since OS X was released.
Andreessen's complaints about hurting the tech industry probably wouldn't exist if Obama had thrown the NSA under the bus. The reason American companies are getting blowback is because of how unrepentant the government appears.
> Of course not. Such a spec would state what are its inputs and outputs, either as natural language descriptions or as types (say, if the reference language supports it).
So you agree it wouldn't work for specs to be "written as executable reference implementations in a well defined programming language"?
> Everything outside that (e.g. timing) would be fair game to optimize.
But sometimes you want to specify performance characteristics.
The simple fact is that without just embedding a traditional spec within it, an implementation cannot tell you what aspects of its behavior are "specified" and which are just implementation details. This makes reference implementations inadequate specifications. That's all I was getting at.
I think you're unintentionally moving the goalposts here. The idea I was questioning wasn't "Specs should be written in something other than English," it was "Specs should take the form of an executable reference implementation." AFAIK railroad diagrams are not executable. I'm also not sure how BNF is supposed to specify things like "the map function applies a function passed in to each argument in a list".
If that's the spec, how do we know which aspects of the executable are really part of the specification and which are implementation details? For (a somewhat extreme for the sake of illustration) example, if the spec is written for Ruby 1.8, do C implementations have to intentionally slow down to match its execution speed?
The MySpace interface in and of itself was OK, especially for the time when it was made. It's what MySpace allowed users to do with it that was an abomination.
LLVM is really how NaCl should be done anyway. The idea of compiling your Web app for a physical hardware architecture is completely backwards, particularly now that there are two families in wide use among consumers.