knappador

Did not eat the 1/3lb hamburger at A&W. Knows math.

Who is building the engine?

One reason big machines might make a comeback is the increasing capability putting off the super-linear cost growth into the realm of > 100GB in-memory or > 10TB on disk. CPU hasn't kept pace unless you consider GPGPU or Phi parts.

Super-linear disk cost back when disks were already atrociously slow compared to the rest of the machine have largely gone away with SSD's hitting huge capacities and tech like NVMe, solid state RAM modules, and Intel's upcoming Optane tech ensuring that more than ever, scaling horizontally can be put off way more than used to be possible.

If you look at scale-out vs scale-up for any applications that were disk limited, disk performance is now ridiculous - > 1GB/s and IOP's measured in 100's of thousands. I'm expecting a bit of a comeback for HA over HP. More than likely, your app can be served well by a single big machine that is well within the linear scaling regime, and you need several for durability and geo-availability.

Credentials would tend to support the practicing endocrinologist. Also, the data Lustig really had to go get was the causal inference where increasing fructose had a delayed response of increased metabolic syndrome. That study has been done now.

I've heard a lot of enthusiastic talk of entity-component architecture from those interested in game-dev. The way of modelling seems very appropriate and well-suited to C++. Things like holding each entity in a component class's static member array and calling the static method to, for instance, update the health component of every health-having entity is just too elegant not to appreciate. Immediately the problem is mapping each component across threads and just trivial to make parallel/concurrent.

To start though you need multiple inheritance likely to get this to work idiomatically. C would also do fine, as would Java, except the Java would look like C because of the lack of multiple inheritance/mix-in, while the C code could result in some type insanity -- although components can be implemented as simple structs in structs for entities, except the whole construction/destruction phase of life.

As an outsider looking in, C++ seems filthily well-suited to game development.

It's incredibly counterproductive to make statements like in the title. If you need your product to be better in terms of how it looks and feels, you get a UX Engineer and expect them to be able to do data analysis, modify analytics on their own, and apply what's learned from that analysis in dimensions beyond the X and Y in Photoshop.

Reducing a task graph is exactly the role that I'd expect a UX Engineer to be perfect at, and yet the article is titled "Engineers Build Ugly Products" while going on to state exactly the expected benefit of having a UX Engineer deeply involved with the product team -- reduced tasks, focused functionality.

Where this kind of thinking blows back on real decisions is when someone says, "Look, I know how you engineers think..." suffixed by some opinion completely drawn from the realm of speculation. Subscribe to such thinking if you want to arbitrarily override the work of your best modelers.

The absolute worst kinds of push-back are fueled by identity politics statements like these bait into. You wake up in a conversation about prioritizing core value and someone pushes on wanting to change the color of the drapes and calls the entire engineering team anti-design like we don't get anything outside of text-highlighting in our code editors. It's infuriating.

Safe points, jit, and VM all introduce extra layers of complexity. I bet it's definitely harder in the context of the JVM muddying up the picture.

Also true. Still, purity (just part of referential transparency) should be highlighted as something that helps not just with the function you're writing , but also functions that need to call that function.

A referentially transparent, small function, has always been easy to write bug-free assuming the OS doesn't lose a page-table entry, a network interrupt isn't exploitable, and cosmic rays don't flip bits. The issue has never been that we can't write something that's correct.

Getting that correctness to propagate because of the strictness of all the tools involved and accuracy of their construction is the issue, which leaves us with needing to either automate proofs with Coq or prove things in more general ways that lead to undecidable problems etc. Still, the fact that one function can be written bug-free and known to be bug-free does indicate that it's not an inevitability of probability playing out as code grows.

We have null-pointer exceptions and no maybe type. The API's that emit nulls sometimes make me expect sewage to leak from light sockets. It's possible to do better. We just don't, and none of us love it. Rust and Kotlin are at least very exciting. I'd like to understand some Coq more in the context of x86. What routines are strictly necessary to even do Coq? A response based on some statement about how the Y-combinator enables X where X leads to Y would not surprise me.

I started to answer this as a language syntax question, but it really seems like a big API problem. And yeah, just cram them and learn the signatures well. I'd just read a lot of library code and follow along in some hello-world scale examples.

Right. I had a moment of severe mistrust develop around all the times I've heard the phrase "neural network" mouthed in a pitched voice after I studied the math and realized it was barely cooler than Taylor series approximation. For a moment stacked Boltzmann machines were going to stay in obscurity, but then they became "deep learning" while also solving real problems. If there is one thing I could contribute to the popular programming lexicon, it would be making sure that the phrase "isomorphic" gets used for something other than javascript.

Not two years ago I was having a conversation with an old friend that went approximately:

"Facebook, this whole internet thing, hasn't really..."

"...worked out"

"Yeah, this isn't what we thought it was gonna be. Let's just... "

"...turn it off"

There was a belief implicit in the idea of every human on Earth being connected. Many of the phenomenon that came about have made that belief look vulnerable to a certain cynicism, a cynicism about humanity, that we fear in each other, that we hold towards ourselves. A currency that bound us together face to face became fiat and then failed at scale. It is within the vacuum painted by this fear that the organizing effects of the old-world economy have been fallen back on, but I do not presently fear this cynicism, and I save my currency wherever I can earn it.

Don't count out Kivy for a modern UI toolkit, but speed and no requirement to include a runtime for distribution will not come for Python without a different approach to execution.