When computer people name things, it is with a tenuous grasp of meaning of the words they are using. You kinda have to roll with it.

If you are really enthusiastic you can write _obsfuscated_ C. And people can kind of agree what that is when they see it.

But _idiomatic_ ? Good luck defining what that is.

The term has sort of stuck in Python and there it's purpose is a bit more clear. There is this _object_ way of doing things, there is this _expression_ way of doing things etc and the interaction patterns work really nicely.

But you can't really use that expression in other languages which lack the same level of institutional design without sounding very much out of touch.

And now a days in the age of Denuvo and things like this, cracked binaries are sometimes even 'cleaner' than the official releases.

It'll be interesting to see if LLMs do increase the rate of completely cleans.

Funny thing is they removed all their blogposts on Griffin (an obfuscator several anticheats, including EA's, Riot's and FaceIT's utilize) for whatever reason.

Besides it’s good to take things slow when face to face with people.

This is so strange. To my mind the only purpose companies hire engineers is to support business. The staff engineer should not need a project manager to tell what is interesting for business aspects - even though the goals are likely mostly technical.

I do realize this does not hold up always. But to me if you can't provide some reasoning for your work in business metrics you are participating in an academic exercise.

Lots of hires, especially in places big enough to have dedicated teams for platform work, are for empire building, rather than to support business needs. In these situations, companies hire engineers because a higher-level manager needs to increase their headcount, in order to pad out their CV for their next move.

[0] https://www.investopedia.com/terms/e/empirebuilding.asp

The OP is discussing tasks to do, you sound like you are discussing things that need to be done. The OP isn't saying there aren't things to be done, they are saying that no one is going to tell them what needs to be done, so they must discover and formalize it.

"Inventing Work" is a bit tongue-in-cheek.

For processes that are scalable, well known and industrial, profit motive actually does provide results.

The question is more of are there bottlenecks of skill and maybe secret sauce (eg something like ASML).

I suck at math myself so can relate. But actually the math you need to learn to be effective at graphics is mostly about understanding _a very small subset_ of a bunch of concepts (such as how 2x2, 3x3 and 4x4 matrices work) and one is set for life,

so I think it’s good to give the formal mathemathical explanation and then Gilbert Strang what it all means.

But camera transform is so unintuitive it really helps if the student tries to work it out for themselves why it works.

For me it’s really weird anyone would write code and _not_ start from reading all of introductory computer graphics literature because it’s so awesome but I realize I’m the outlier here.

Practical computing is not and never has been an abstract pure concept. It’s about making machines built by corporations to do usefull things at scale.

There is no ”non proprietary” computing unless you make your own stack.

It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gauged hardware.

This is wrong way around.

If you don’t support the platform your app runs on using the native api:s to the hilt your port is just bad.

If you actually want to support multiple platforms _you actually need to support_ them from the ground up.

This is speaking industrially and businesswise. A professional software business always has per-platform implementation resources. Or they have just one platform. Or they pretend they are multiplatform and then _everybody_ _daily_ fights with the problems this causes.

Obviously those elements that can be portable should be. It’s like Einsteins simplicity maxim - your codebase should be as portable as can be but not more.

” It’s even worse for CUDA…”

No these are just the business and market constraints. If this does not make sense for your offering then don’t use it. This feels like false FOMO - CUDA is not a silver bullet but it might be a specific solution to a specific problem.

And Re: CUDA: yes if it doesn’t make sense then dont use it. That’s sort of my whole argument. It might make some level of sense from a technical perspective, but that needs to be balanced with business risk. I’m saying a lot of people aren’t doing the balancing right, which is why these new tools have value.

This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows.

Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in.

And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.

That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way.

But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.

That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.

> Dead wrong [...] if I want to release a binary _without relying_ on Win32

Then you are not using the Win32 ABI, are you?

Also, there are OS-provided shims in ntdll.dll (which, by the way, isn't a part of Win32 platform API, but a part of the NT kernel interface).

Once this is accepted the rest becomes easier as you are not wasting time trying to find a silver bullet.

I mean it’s then ”just normal work”.

Is this still true? eg, Shopify saying porting is now easy so no need for abstractions.

I mean _it's just work_. You don't need to invent anything. Just do the work.

What _is_ hard is when people run after silver bullets to avoid all this work.

Because people who don't understand software decide it would be cheaper to implement something only once. Or someone who does not really understand what they are doing insists that same C++ code runs automatically on all platforms.

AI has given the software engineers permit from the beancounters to do the sane thing.

Good software development orgs _have always_ done proper per platform ports.

Also - there is nothing wrong in supporting only one platform as such!

I really wonder why this was never fundamentally fixed. How performant a certain instruction on a specific platform is, how well it is supported and potential equivalents or sets of other instructions to emulate an equivalent are usually all very well understood.

So there should be some graph of operations which can transform any software from and to the specifics of each platform. Especially because firmware + compliers + platform abstracting libraries are basically already just that graph, although (usually?) to lossy to be applied in reverse. Add the recent developments in very large scale statistics to it and it'd probably be quite possible to transform from and to generic intent in the implementation to the uniqueness of each platform. E.g. the theming differences between a MacOS UI and a terminal application served over serial or the processing capabilities of a VLIW CPU compared to a FPGA or a GPU server.

Considering the enormous amount of work that went into compilers, better debugging and intermediate representations it seems like a huge missed opportunity nobody seriously asked the question whether information could be emitted that would allow for decompiling all the way back to the generic intent.

For example, if you have a program that just does raw math and pointer arithmetic and data structure manipulation —- that is, pure computation — then porting it to a different CPU might well be trivial. Just recompile. As long as your language toolchain supports it, this will Just Work.

But if your program works with the filesystem and sockets and threads, then it’s less likely to work. This is the promise of POSIX: if your program uses only what’s offered by the POSIX standard and uses those functions correctly, then it’s supposed to work on any POSIX-compliant system. Just recompile.

But if your program has a GUI, or does 3D graphics, or uses special methods for high-performance networking, or accesses gyroscopes or accelerometers or touch sensors, well then you have to do work to port. And notice that this work isn’t about which CPU instruction to use. It’s about figuring out —- deciding —- what the right thing to do is, for your app, given a slightly different set of available system capabilities.

SketchUp does not really have that either if you are expecting something else than triangles. Since sketchup has polygons you could argue they are brep but even then only accidentally.

Architecture works with a bit different ruleset than mechanical cad.