This exists in many parts of the world. And is usually reserved for the ultra wealthy, especially if you want it to be near a big city. One famous example is Karuizawa.
Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.
Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses is equally readable as Seuss's The Cat in the Hat?
I see this argument pattern a lot, so looked into what the name is.
Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.
Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.
Add "to most developers" for context and you'll probably get exactly what original claim meant.
It's not a non-statement. Rich Hickey explains it well, readability is not about the subjective factors, it's mostly about the objective ones (how many things are intertwined? the code that you can read & consider in isolation is readable. The code that behaves differently depending on global state, makes implicit assumptions about other parts of the system, etc - is unreadable/less readable - with readability decreasing with number of dependencies).
"to most developers who are most likely to interact with this code over its useful lifetime."
This means accounting for the audience. Something unfamiliar to the average random coder might be very familiar to anyone likely to touch a particular piece of code in a particular organization.
>"Code should be readable" is a non-statement, yes.
Oh, I completely disagree here. Take obfuscation for example, which you can carry on into things like minimized files in javascript. If you ever try to debug that crap without an original file (which happens far more than one would expect) you learn quickly about readability.
>> Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.
Usually that means something less than "perfect" from the perspective of the writer. Applying to much DRY, SOLID, DI and other "best practices" will make it very hard to understand. Pretend you have about 20 less IQ points than you actually have when writing the code - you will thank yourself when you come back to it.
> Reading -- and understanding -- code requires twice the brainpower of writing code. So if you used every bit of your intelligence to write 'clever' code, you won't be able to maintain it because it requires twice your intelligence to read it again.
Einstein's words are oh so suitable as well:
> Everything should be made as simple as possible, but not simpler.
The trap people fall into is calling The Cat in the Hat unreadable compared to Joyce's Ulysses because The Cat in the Hat they're reading is written in German and all they understand is English.
I didn't say readability is subjective. I'm just asking, when someone says "code should be readable" without any clarifications, what does it really mean?
Big companies may actually have an answer to that: "since we require at least 2 years of experience in the area from new hires, all code should be readable at that level".
However startups may prioritize something else over readability at that level, for example: move fast, produce the most minimalist code that would be easy to maintain for people like you.
My point being, "code should be readable" should always come at least with a footnote that defines the context.
You'd be surprised how complex a typical memcpy implementation can get to eke out all the performance out of a platform for all the possible scenarios. And while I agree it might not be considered an algorithm in the strictest sense, in response to OP's question, I think memcpy is an apt comparison.
SteamOS is a much more streamlined console-like experience for gaming. Even things as simple as system updates is far less annoying on Linux/SteamOS than it is on Windows. This is especially important in, for example, a set-top box media PC you might want to have for your TV and you don't run every day.
And, over time, as SteamOS in its various forms becomes more and more popular, game publishers will be motivated to support it. Many already are, from Steam Deck alone. And, in a few years, it's possible that a "casual PC gamer" will actually prefer the far more plug-and-play SteamOS experience versus the Windows one (which, I, for one, highly dislike, but I understand that's a preferences thing).
One of the reasons why they can do unified memory efficiently is because the CPU/GPU is a single SoC. If you separate them, you end up with a normal PC architecture, with memory having to go through a PCIe bus. This is possible to do with reasonable latency and bandwidth (thanks to CXL), but we haven't seen that in consumer hardware. Even in server space I think only MI300 supports CXL, and even then I don't think it's something AMD particularity promotes.
Personally I think Strix Halo workstations may come with expendable memory, storage and free PCIe slots. But then you have to deal with ROCm...
At least for Intel, that is just not true. Intel's DPC++ is as open as it gets. It implements a Khronos standard (SYCL), most of the development is happening in public on GitHub, it's permissively licensed, it has a viable backend infrastructure (with implementations for both CUDA and HIP). There's also now a UXL foundation with the goal of creating an "open standard accelerator software ecosystem".
This is all great, but how can we trust this will be supported next year? After Xeon Phi, Omnipath, and a host of other killed projects, Intel is approaching Google levels of mean time to deprecation.
The Intel A770 is currently $230 and 48GB of GDDR6 is only like a hundred bucks, so what people really want is to combine these things and pay $350 for that GPU with 48GB of memory. Heck, even double that price would have people lining up.
Apple will sell you a machine with 48GB of memory for thousands of dollars but plenty of people can't afford that, and even then the GPU is soldered so you can't just put four of them in one machine to get more performance and memory. The top end 40-core M4 GPUs only have performance comparable to a single A770, which is itself not even that fast of a discrete GPU.
I've been using Gemini-1.5-Pro-2M through Poe for creating e-book recaps and just generally interactively jogging my memory about a prior entry of a book in a series when a new one comes out. It's been working surprisingly well, even for very large books.
Is the alternative "mass hacking"? I thought all this software did was check a box on some compliance list. And slow down everyone's work laptop by unnecessarily scanning the same files over and over again.
Combined with the fact that Intel created both CXL and Optane, it stands to reason that the plan was to combine them eventually. Unfortunately, that was never came to pass :(
Xilinx made triSYCL (https://github.com/triSYCL/triSYCL), so maybe there's some chance AMD invests first-class support for SYCL (an open standard from Khronos). That'd be nice. But I don't have much hope.
