I don't know, I was very happy when I discovered what Radiance can do with what you give it. I hear people get very good looking rendering with Blender, but my brain doesn't work like that (anymore?). Point being that not everything is about games and looking good, we need reliable tools to render synthetic scenes to assess a lot of non-game related things, like quality of lighting in architecture before erecting a skyscraper or buying a house etc. To that end, every bit of knowledge like the author seems be focused on, helps. I absolutely relate to the problem with "faking" things. Even developers of Unreal engine had acknowledged -- all too late, as it is -- that it's _light_ that most affects our perception of "realism". That and materials, which is why they had some sort of field trip to Iceland taking raw photos of rocks they could add to their materials library.
Another problem with looking good is that it's a) subjective (since it has no real or objective reference point, really) and b) it quickly goes stale once something else looks "better". Just look at Doom. It looked good in 1993, everyone would agree on that. It's not realistic, never was realistic and will certainly never be realistic unless you take a particular cocktail of drugs, I guess.
Is transcription a form of _inference_ though? I mean I see the word being thrown around and I understand what it means (or at least I think I do) in context of LLMs doing the thing that they do -- intelligently predict the next token, but do speech-to-text models do that?
Ok, I admit arguing about Git's merits, best practices, workflows and so on, can be hard online like this, not the least because I have limited amount of time I can invest in this admittedly very interesting to me discussion, so it requires upfront reasoning (in addition to the typing, which is relatively cheap) but I feel obliged to respond.
First, I agree commits shouldn't store broken snapshots -- if that's what you mean -- code that doesn't compile or outright is _known_ (as opposed to omissions that weren't caught otherwise and made it into the commit) to be broken, not run, produce runtime/type-checking errors, miss dependencies/assets etc. Not everyone would agree -- in our shop people routinely commit "stuff" for reasons they don't disclose that also remain unexplained to me (not having any explanations my way), and then more stuff on top of that. At some point they tag one of these commits as "v2.0.0" triggering automation that releases a package, often broken. Then they scramble for "v2.0.1" etc. I find all of it tedious and unnecessary -- my best practices would rather be to run automation that does checking and sufficient filtering for "bullshit code" as early as possible -- at the "pre-commit" stage, so only whatever passes through that ends up being committed in the first place. If it yet runs into regressions or other problems in production, I fix (re-triggering all the checking again) and release a strictly patch version -- unless fixing was impossible without breaking compatibility in which case it may be a minor or even a major version bump. I do tag commits, too, obviously. But in principle every commit is "production", the difference is not every commit makes up a _release_ (implying to the general public / intended audience).
Regarding rebasing -- that depends on what you mean exactly -- there's different ways to rebase -- you can squash, auto-squash and/or apply fix-ups, or you can just transplant stuff -- when you say "you should rebase" and "patch on current master", what do you mean? Github-driven projects often don't permit pushing `master` without a PR, so a rebase upfront would have been necessary if the author for some reason is not on a branch [other than `master`].
"Actual merging" -- do you mean merge commits as opposed to fast-forward merging which doesn't produce an additional commit? If the latter, what does "merge from history" mean, again? You just need to produce a working snapshot, expressing it with a commit with N parents, there's no more to it. It's fixing of the merge conflict that requires you to understand the graph, the resulting commit is just the period at the end of a long sentence, so to speak.
Anyway, I really missed the point you were trying to express with your first paragraph, I am sorry. Do elaborate, please.
Bisecting also _benefits_ from non-linear "actual development" graphs -- apart from commits that don't feature broken code committed haphazardly for "reasons" (some people use Git as backup, that I know for a fact) -- since they don't hide the work (one of the reasons I prefer raw graphs over squash-merged "polished" stuff).
One thing I should mention in any case is that I do find slicing work into atomic commits often very tedious and counter to what Git is supposed to sell (distributed friction-free concurrent versioning). Because my brain doesn't always work in terms of concepts aligned with Git's -- I routinely may start with one feature fix, on some branch, then discover N related issues, fix those because they're in front of my face then and there, end up with an unreadable diff I can't cleanly add in chunks, etc. None of that is facilitated by Git in any more capacity than just being a scalpel. I don't always want to cut down a tree with a scalpel, obviously.
Pijul, an alternative VCS, uses this nice patch theory guaranteeing you can "apply" commits in any order, compositing your changes essentially -- a feature is just some baseline that is added N commits (in any order, like the mathematical `+` operator). That way you don't have to rebase anything because parenthood doesn't break merging -- if you fix a bug with a patch in Pijul, you can store it once and count on it being applicable to any snapshot made later, even if the result isn't visible -- unlike with Git where rebasing some old commit will abort and ask you to fix a conflict because Git cannot continue.
I think you missed the main point of my argument -- you, the game developer, aren't programming the hardware directly or through the kernel -- you are using a common abstraction in a competing set of abstractions that don't require their vendors to beg for crumbs from the likes of NVidia because the dependency only goes the other way -- NVidia publishes an "exokernel driver" that merely exposes the capabilities of the hardware without assumptions about how to best use it. Fundamentally it's not even needed beyond a _specification_ since the hardware is fundamentally exposed through ports and addressable memory mapping(s), but since Nvidia does closed-source and closed-hardware the latter is not going to happen so kernel driver it is. You, the game developer, don't use it directly, you rely on middleware (like Vulkan) and/or middleware on top of that middleware and so on -- until you are left with an API you are comfortable using.
Indeed, Vulkan is the step in the right direction because it largely follows the path I was outlining, but it's still got ways to go because it assumes things and mixes in abstractions of its own, but more importantly because through its mere existence and the way how it is positioned it occupies space where nothing else has room to exist. Point being that Vulkan still requires you to play by someone else's rules of how they thought the API should work, which is detrimental in principle to "exokernels". So this is about exokernels, not about going full retard and programming a 100 billion transistor GPU on your own to draw pixels.
In case I wasn't able to elaborate: Vulkan looks like the part, it's certainly a sign of the people who started with the likes of DirectX have learned about the dead-end model they thought would work and are now finally seeing the "light", and I am arguing that whatever abstracts the GPU should just pretend it's a generic massively parallel computation unit with addressable memory of multiple kinds and places and so on -- without assuming it's for "graphics" (which it is less about today than ever before, what with AI etc).
If you want that, mandate developers use prefixes like `!fixup` and do `git rebase` _on your end_ -- why force upon everyone your ideas especially if it also squashes all development history? This also removes development friction because people can work with Git on their end the way they like without regard to some convention that can be avoided -- save for the "!fixup" thing which can be considered useful metadata.
A linear graph doesn't do any developer in the team except Github (which isn't a developer in this context) any good because they have to pull down the graph at some point and when they have to fix something, although they will be able to track the blame to some commit in the middle of the graph, when they fix it and merge it it has to be squashed again (by hard or soft enforcement), which like I said negates much of the point with Git -- there's no usable history left.
Point being that branches aren't something to avoid, implying that complicated graphs are not to be avoided either, but embraced and knowing how Git works it's not a problem at all (unless your "bush" is accidentally complex in a bad way) -- except that if noone bothers to learn Git, it _becomes_ a problem, solved at the cost of the value that Git provides -- branching (not just ephemeral branching for your local convenience). Exacerbated by Github since everyone pulls from there -- meaning that production-grade code is not a true graph but a linked list, on average.
My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentially immutable), they don't venture farther than their confidence suggests, keeping it within the circle so to speak.
The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper).
Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either.
For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... <commit>` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that).
I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message.
But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best.
Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...
I last wrote 3-D rendering code using hardware in 2005 or so. It was DirectX 11 or 12, I don't recall. I thought it was quite a mountain to climb. For my part, I grew up _implementing_ rendering pipelines, so I always had this sour taste of needing to learn someone elses (Microsoft, in this case) idea of how to render 3-D scenes -- using their concepts, even if they were industry standard (shaders etc). Meaning that somewhere inside their APIs are fundamental abstracts I _do_ find, well, accepted terms. After all, I am not arguing against using integration in maths as being useful. There's practicalities.
What am I getting at?
Well, if you take the "no graphics API" to its logical conclusion, then we should strive to remove everything that is "graphics" from it altogether. Reading the article linked and the article the former links in turn ("No Graphics API"), there's still an ungodly mix of graphics rendering _specifics_ and I think these too will start rotting "sooner rather than later".
Having grown up on matrix operations and optimisations that often venture into territory where they _lose_ resemblance to outright _graphics_ pipeline they originally modeled, I am of the firm opinion the logical conclusion I am advocating for, is a sensible one.
To explain with an analogy -- I think we should adopt the "exokernel" approach to GPU hardware. That means just exposes the hardware constructs without trying to fit these into any form of a common denominator (between AMD, NVidia and Intel), and have software specific to each glossing over the abstractions.
Before you say "well, that's exactly what DirectX, Metal and even Vulkan, did!", the key difference is not the encapsulation itself, but its form, the "how" of it.
An exokernel, for instance, does not expose or provide a memory manager (referring to use of MMUs), or give you a `malloc`. It simply exposes the paging mechanism, and you take it from there. If you need a high-level API and/or cannot be bothered to page things in your little command line application -- a fair concern -- you rely on middleware, aka "libOS" in the original, MIT's terminology, a library by any other name -- to provide `malloc` so you don't have to cry over the bare-bones exokernel.
The point I am making is that as the exokernel software (and libraries that would complement it) just exposes the GPU hardware, there is more flexibility to how to use it without "cramming round shapes into square holes" -- a bane of graphics programming _and_ especially optimisation there, that has plagued the entire field since 3dfx' days. Library authors can wrangle API design without touching the hardware or working _around_ it, while hardware vendors can tune subsequent chips to generic computing -- it's the way it's going anyway, except that they won't have to coordinate closely with software writers -- the dependency will go strictly one way -- from library to "GPU exokernel" authors to hardware manufacturers, and never the other way around (ideally). Every link in the chain has more flexibility then.
Practically, we're talking about a generic massively parallel processing unit with tons of addressable memory of different latency (system RAM, on-board RAM, on-chip RAM / L0-level stuff) exposed with a zero-cost abstraction layer known as an "exokernel". DirectX / Vulkan etc compatibility implemented strictly in software over the "exokernel". Those who want their retained mode or whatever else that doesn't require them to deal with cache thrashing issues, can use that, while those who like to holistically optimise and/or Unity / Unreal Engine developers proper, can use the exokernel by writing libraries for it, or outright affect the exokernel itself as new hardware is put on the market.
Sorry for the wall of text. This is from someone who started with implementing solid-painted triangle and polygon rasterisation, then Phong and Gourad shading using an Intel 386...
P.S. This isn't AI slop (although you're obviously free to feel it reads like one), I just like to use the em-dash.
I think a fundamental and flawed assumption in your general line of argument boils down to that line:
> Social people will be fine
Thing is, "social" is not only a scale, it's not even a line for scale. It's this multidimensional space of different social preferences and different preferences as to _how_ to socialise, not to mention with whom and for what reason. In short, it's much more complicated than as to permit a "binary" division into the "social" and "other" people, but even if you did, I would wager the division puts it at 50% for either group, meaning you're basically describing a cataclysmic event where 50% of the population suddenly has no access to a fundamental trait of humanity that in known and unknown ways has assured our feeling of happiness and warded off a plethora of conditions of misery and worse that psychology has no names for (and won't ever have names for because that's like classifying different gradations of drinkable water, I imagine).
But yeah, humanity has always had to evolve, it's just that these changes come too fast for our adaptability to adapt to, I believe.
Fewer people aren't staring into their phones or talking to them -- makes your social antennas pick up automatically on not wanting to disturb them (lest you draw their ire for not having the social antennas long enough to pick up on the fact they're "busy and don't want to engage with you" like a gymrat with AirPods to signal they're there to pump in peace and quiet listening to their favourite playlist, not talk to strangers). Happened to me already many times just with people scrolling their phone instead of talking and not wanting to talk in particular either, not to me at least. And no -- I am not talking about bothering strangers in the gym etc, I am talking about sitting at the lunch table where half of the people look into their phones -- they aren't actually interested in talking, it turns out.
Our devices have now increased the distance _between_ us -- it's not about _you_ being able to "do X" -- talking to others is not _you_ doing it, it's you _and the other person_ doing it _together_. You can't be doing anything together consentually when the other person is in the habit of talking with their AI, or doomscrolling for that matter.
Right, if what you mean is making the `=""` optional, then it seems even more attractive than types, I admit. You'd have to amend the XML grammar to see if making the `=""` optional introduces problematic (for e.g. the reference parser) ambiguities that weren't there before. From the looks of it / intuitively it doesn't seem to be the case, but with a language that's deployed in a gazillion places such small changes rightfully warrant new major revision, which would be XML 2, I guess. Which would have wide ramifications, I imagine. Which brings me to W3C....
> True however those who control the HTML spec are unlikely to let it go.
Like I said in another comment, I believe XHTML was axed because it stepped on _someone_'s toes. I suspect it had to do with W3C being understaffed and criticised for being too slow at the time -- by most of the industry, and most of it deservingly -- and WHATWG (with Google co-authoring their standards) stepping in as the authority on all things Web, and somewhere between the two XHTML was used as the proverbial fall guy. Speculation, of course -- but a lot of good, useful work was thrown out the window with XHTML. Not the first time it happens, of course, but this was the Web we're talking about, not Adobe's product portfolio.
I've heard the "streaming" argument before, by the way -- it keeps being mentioned (probably because it was one of the official reasons for the transition to HTML 5), but I think it's a "ruse" -- nothing about XHTML in practice prohibits an agent from progressively rendering an XHTML document, and if something really did, in W3C's writing for instance, then all they needed to do is relax that requirement because again -- there's plenty of hierarchical data formats with strict rules that by their very nature don't preclude parsing (or semantic analysis / rendering) done in streaming fashion.
Can you think of a minor syntax error example that you believe should be corrected by the browser, and better than the author would (had the Web browser notified them early -- by aborting rendering as was the case with XML)?
There's a bit of irony with the fact that HTML 4 which _did_ have browser "correct" errors (albeit in non-standardised manner) _was_ what motivated XML in the first place -- it's just that in light of the wildly different correction behaviour between Netscape Navigator, Internet Explorer, etc, they decided on a pragmatic solution -- abort and tell author, like a C/C++ compiler. The latter can also correct syntax errors, strictly speaking -- but you'd be hard pressed to find a programmer that would seriously consider letting the compiler do that. Why HTML should be different?
Say you forgot a `</p>` and then comes a `<li>` -- since `li` elements cannot be children of paragraph elements, I guess the Web browser, in compliance with HTML 5 for example, could mandate that the paragraph ends just before the `<li>`, meaning it behaves as if there _was_ a `</p>` before the former, _and_ also inserts... what, a `<ul>`? Why not `ol`, then? This heuristics is messy, if only because the Web browser doesn't have enough context to _know_ what the author wants, and can't assume a single kind of omission. And HTML 5 simply defines some default behaviour, handwaving the problem, but the truth is no HTML 5 authors -- myself included (I have been writing HTML in one [proto-]form or another since 1994) -- ever remember what those rules _are_.
I think this is _the_ most popular criticism of HTML 5 vs. XML, that I have seen mentioned. Which is telling, quite frankly. It makes me think that the powers that be that pushed HTML 5 really had a different agenda than what they purported to have. We might never know the politics behind it, but I struggle to comprehend the wisdom of a decision to basically overhaul the lingua de franca of the Web because "XML parsing is hard!" then replacing it with HTML 5 and its peculiar "context sensitive grammar" noone ever remembers or bothers to look up, and the other features like custom elements (with the latter, by the way, in the spirit of "let's just ship it and see", they kind of foundered with the sub-classing there -- Apple rightfully refuses to implement some of Custom Elements API because it flies in the face of Liskov's Substitution Principle).
I looked at CSTML, and frankly, it looks like any other improvement that upon first glance may seem like definite improvement, but the trouble with these dialects or ideas is that it's not the format that's hard to incorporate -- even after you prove it is sound (undesirable parsing ambiguities can something show themselves _after_ you wrote a parser to verify the language grammar etc), but pushing for adoption is. XML didn't die only because it was verbose, it died because the people who may have been convinced of some of the featured really disliked by everyone else, refused to budge -- perhaps they thought that repeating the tag's name is a good thing because it forces one to be diligent or whatever * points to some research paper that supposedly proves repeating text improves accuracy *. It's the equivalent of doubling down when opposed. So XML basically became more XML the more criticism piled up, and as it ossified it died. CSTML, as likely much of anything else that aims at replacing SGML/XML/HTML, is like projects -- ideas are cheap, going through with it is hard. Before CSTML is a long path of adoption, and today with HTML 5, it's even more narrow unless Google, for one, suddenly decides it's the best thing since `<parsed-bread>` (closing tag is omissable).
I think some straightforward YAML schema for representing HTML 5, may have more traction because both are existing languages so not much extra tooling would be required. I could for instance write my Web blog in YAML that is unambigously and simply compiled into HTML 5 (without sacrificing a _single feature_ of the latter), so I don't have to actually type HTML (5). Not everyone uses React or JSX or what have you, and Markdown implementations in practice are often lacking for truly rich blog articles. Then again, if you have a blog article with interactice diagrams, sliders and ad-hoc questionnaires, _XML_ (or a YAML representation thereof, for much the same reason as outlined earlier) _is_ IMO a good language _in form_ -- I have used XSLT with good effect to just stick to a domain-specific language for my blog articles, and have a single XSL stylesheet render uniform HTML page linked to a CSS stylesheet that was basically a posterchild for the coveted content-presentation separation in practice.
I agree we shouldn't have thrown the baby out with the bathwater -- and it's not like _strictness_ was not in XML's spirit, so your usual suspects for primitive types -- numbers and booleans, to name a few -- _could_ have been an improvement along the XML's path of evolution. But something tells me that these features only open a door to more features that are needed. The bounds on what constitutes the [sufficient] set of fundamental types, is a hard problem to solve, especially if it cannot be extended through itself (composite/compound types). XML had not anything but strings for attribute type, but that also made it simple and kept it away from the domain of type theory and parsing more than it already had to have parsed. So I am undecided, but I liked the "one good feature of HTML 5" part of your comment, so I took your bait ;-)
XHTML, as has been _repeatedly_ mentioned by multiple people -- a thing that comes again and again -- at least was _strict_ in that your malformed document told you _early_ (or, rather, a compliant XML user agent did, like your Web browser), where with HTML it's your users that find out, except they have no clue what's going on -- they know even less about HTML 5 parser than the author does, staring at something that should have been a list item but becomes a table cell element or some such.
If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive -- machines do much better with strict bounds than humans do, so if humans aren't writing HTML, then it feels like we've been sold on the wrong premise, even if retrospectively.
Every time XML comes up, I feel obligated to share my opinion (I too wrote XML a the turn of the millennium and have seen it become and still witness on occasion it being excommunicated).
XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.
What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.
What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.
YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.
The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.
Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.
In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
These were my thoughts more or less, but how many Chens does the world's largest software company need to at least maintain the now "legacy" code before they find a way not to need them any longer. Maybe they're betting on large language models having trained on the cumulative output of experts like Chen, but I think that's fit for contingency situations -- maintaining existing code and making sure it doesn't break the bottom-line -- but for all the praise of AI I have my doubts Microsoft are crazy enough to just leave it to AI to develop Windows containing hundreds of thousands of SLOC of the kind only Chen can effectively debug.
As for 25 year olds -- I am sure there will always be those around, people have been pretty consistently varied in their pursuits, but it going to be so niche they'll be like COBOL/FORTRAN developers hired by the banks today -- far and in between and paid so handsomely they can pick and choose consultancy any day of the week anywhere in the world. So I guess good for them, but again -- can Microsoft depend on that form of provision of labour they still need (and will need for a few years ahead at least)?
Another problem with looking good is that it's a) subjective (since it has no real or objective reference point, really) and b) it quickly goes stale once something else looks "better". Just look at Doom. It looked good in 1993, everyone would agree on that. It's not realistic, never was realistic and will certainly never be realistic unless you take a particular cocktail of drugs, I guess.