MillenialMan

I don't think it's about money. Software engineer salaries are very high, and cubicles are a compromise that still saves space. I think it's because for most people, procrastination reduces output a lot more than distraction and noise, and they procrastinate less when everyone can see their screen.

I get what you're saying but I think it generally does the opposite. People like prestige.

The vast majority of titles in tech confer more prestige than deserved, because there's no downside to a company handing them out like candy. I don't look at it as a portability issue, the incentive isn't to be accurate to begin with. Inflated seniority is just a perk they can offer that doesn't cost them any money, so everyone offers it. Titles across the industry are meaningless unless you're calibrated to that company's levels.

The reason I'd like the construct is because it's explicit - intent (and the scope/limit of your intent) is encoded in what you create. It's clear you intend to do nothing with that name except symlink to the nested member, so the reader doesn't have to anticipate other behaviour (and can't accidentally do something else with it). Generic assignment doesn't convey the same restricted intent, and it doesn't carry those guard rails.

Really though it's a structure that only makes sense in strongly typed languages, so I probably shouldn't have used Python to illustrate the idea.

GPUs are $3000 because of Bitcoin, not Unreal Engine.

I'd like languages to have some kind of "delegate" functionality, where you can just delegate names to point to nested names without screwing around with ownership - it would just act like a symlink. The scope of that action is limited and clear (and easy for your IDE to understand), and it's explicit that the subclass is still the "owner" of that property, which makes the whole thing a lot easier to navigate.

E.g. something like:

    class MyClass:
        def __init__(self, member_class):
            self.member_class = member_class

        # Delegate one member
        delegate move member_class.position.move

        # Delegate all members
        delegate * subclass.position.*             

Then:

    a.move == a.member_class.position.move

etc.

I stand corrected! Thanks for the link, that's very cool.

Those rivets probably aren't modelled, they'll be reconstructed from volume information in the texture. Which is still impressive and a great way of dealing with that type of geometric detail, but it has limitations, and the engine isn't processing actual models at that level of detail.

You can still do stuff like that in UE4. Have a look at what's possible with Quixel Mixer, you can create detail like that surprisingly quickly. I'd tentatively argue that modelling tools are the real MVP when it comes to increased geometric LOD in modern engines. They allow you to add that kind of detail quickly enough that it becomes economical to actually detail rivets.

Either way, it's very cool. The crowd simulation stuff is going to be useful, current tooling there absolutely sucks outside of a few very expensive dedicated products.

That's not really true. Video upscaling is probably going to be linear interpolation, which is very unlikely to add meaningful artifacts, but an intelligent zoom that tries to add visually meaningful information may change the apparent content.

It's rarely altruistic but this seems very win/win to me. Talent without a record can prove their chops and get hired above their on-paper experience level, Google gets an additional avenue of recruitment.

I understand your point. I'm saying: the subset of problems that benefit in a performance sense from immutability is very small. The vast majority of the time, cache misses slow down algorithms. That's a perfectly reasonable generalisation and I don't really understand why you think it's untrue.

Re: change records, I believe Braid uses a historical record of absolute states, not a series of diffs. The state at a particular time is recreated from a minimal representation (a couple of arrays). That's much more efficient than throwing multiple iterations of the state in a HAMT.

That wasn't really my point. There is still a translation process you have to apply to cross the boundary between immutable and native data structures though, and that has its own overhead.

In general I would agree, but a significant part of Clojure's appeal is that it's immutable by default, because that allows you to make certain assumptions about the codebase. Introducing mutable datastructures means you can no longer make those assumptions, so it potentially has much wider ramifications than e.g. calling into C code from Python.