I think his point is that you should build said code for your specific game or engine ;)

WTH did you think I meant? Of course its trivial to implement. The point is the it *isn't* implemented.

Tools should offer this sort of thing out of the box. Editors should popup little variable editor panels, then auto-recompile the function, and patch it into the running executable.[/quote]
Not with languages we have.

Consider this:template < size_t N > struct OptimizedTexture {
int getWidth() { return N; }
}
Texture is hard-coded to size N by N and pipeline supports that. In a tool I now change N from 512 to 2048 - to see how much better it looks. The simple recompilation now means entire asset repository needs to be rebuilt.

Nothing he shows is impossible, or even very difficult (he implemented it, after all). But in general, people aren't writing this kind of tool, even though it can make one's life so much easier.[/quote]
A system like that exists. (insert obligatory comment about Lisp doing it before everyone).

As with everything in CS and SE, what can be done has been done by mid-70s.

But due to commercial factors, legal reasons and general direction of the market, such open-ended computational devices failed. They also tend to be suited to computational tasks, not IT or consumer devices.

Building a fully introspectable system today is also impossible. Between proprietary OS layer, the opaque hardware and unpublished hardware, all one has left is a tiny sandbox to play in.

Theory of such systems is old. It's the original design of systems, where code = data and vice versa. For example, you take a window, send it over network and it pops up on another machine, fully functional. For simpler unix-like versions see also Plan9 and sam/acme editor.

As for use with today's tools? Not possible anymore. The two most popular OSes are completely gated through legal restrictions making development of such tools impossible and Linux seems to be competing on just how badly it can fragment, making development on anything more advanced that GNU make collapse under its own weight of incompatibilities.

CS ended in 1970s. There has not been a single meaningful advance since then. All systems in use today are merely poor attempts at replicating everything that has been done back then.

But if you have an idea on how to improve ad conversions by 0.3%, then Google or Facebook will pay you billions for it. It can be done in Visual Basic, it doesn't really matter.

I said we need tool support. APIs are tools too. So what if we have to retool database layer to allow on-the-fly shallow-copy-modification of data?[/quote]

That's an architectural issue, not a language issue. Not the compiler's fault that your asset pipeline only supports a single size of image.[/quote]

Let's say my pipeline generates height at some fixed resolution using texture color. Then I plug in Google Maps as texture source. How do you reduce that to a shallow copy, when changing parameters requires full processsing of a petabyte of data or so?

It's a computational complexity problem, we simply don't have enough processing power even for small datasets, let alone those used daily for the most boring of CRUD apps.

And then our tool displays "infinite recursion", or some such. Better to provide UI for finite cases, than not at all.[/quote]

To determine whether it's finite or infinite, you need to solve halting problem.

I suppose that's "simple".

You've exceeded even my tolerance for jaded old-timer ranting.[/quote]

You asked why nobody is building tools like that.

Because we can't. Let's say I want to build a code analysis tools for Windows - I don't have access to WinAPI or compiler, since building Windows applications requires proprietary extensions and VC is closed. I'm only allowed to use existing DLLs to use whatever information they provide.

Heck, I'm not even allowed to set up a build farm for VC, since licensing terms of compiler and SDK forbid it.

I'd like the ability to tweak constants at runtime, and this is eminently achievable. Hell, there's even a GDNet article that manages to set that up in C++ using some unholy macros. Give me IDE integration of those, and I'd be pretty happy.

And I'd like the ability to repeatedly execute isolated functions in a user-defined context, with output of variables at each step.[/quote]

*nix anything + scripting languages + emacs.

This isn't jaded old timer talk. Why are there so many people that are rabid about that combination and won't hear anything about an IDE. To them, IDE is a puny little toy for 3 year olds. And they're right.

But it does require one to completely turn around the notion of what a program is and instead treat everything as computation.

And needless to say, it's limited mostly to shuffling text, simply because drivers and other parts of OS aren't sufficiently exposed.

The obvious caveat is that if a feature is missing, "implement it yourself". But unlike the usual OSS stance, in this case implementing it yourself is just a few lines of code that solve a very specific problem with a very specific part of application. Making it reusable is somewhat counter-productive since it. by definition, limits what can be done.

For C and C++, we lack a sufficiently accessible compiler. Due to sheer complexity, they are a black box. But in ideal case, such compiler would be just a bunch of scripts. Want to monitor a variable? x86mov.prototype.write = function() { ... }
Change register order? Just foo.replace[(ebx, eax), (eax, edx), (edx, abx)]. Replace code? Just take process.image.replace("foo", "bar").

Obviously, constructing a C++ compiler with such capabilities exceeds current capacities (cost/demand) of software engineering, but it's theoretically doable and would bring all the scripting language flexibility to compiled languages. LLVM is a tiny step into this direction. Compilation is essentially just a special case of lazy evaluation.

And again, we cannot ignore the fact that OS vendors then forbid, through legal means, use of such compilers by restricting access to OS APIs, restricting us to basic console/socket applications. Which is much bigger reason why nobody is doing it, outside of Apple who has immediate need for it in form of XCode and ARM/x86 cross compilation.