Sign in to follow this  
evanofsky

Inventing on Principle - amazing video!

Recommended Posts

Antheus    2409
[quote name='swiftcoder' timestamp='1329805059' post='4915094']
WTH did you think I meant? Of course its trivial to implement. The point is the it *isn't* implemented.[/quote]

It's not implemented because you need to fight constant factors, halting problem or NP-class problems at every step.

For a typical wordpress app, tool like that would need to make by-value copies of deployment and database for each editor.
For algorithms, table looks amazing. Until the user types fib(MAX_INT). Or Acekrman(4,4).

[quote]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:[code]template < size_t N > struct OptimizedTexture {
int getWidth() { return N; }
}[/code]
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.



[quote]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 [url="http://en.wikipedia.org/wiki/Lisp_machine"]like that exists[/url]. (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.

Share this post


Link to post
Share on other sites
swiftcoder    18426
[quote name='Antheus' timestamp='1329866126' post='4915309']For a typical wordpress app, tool like that would need to make by-value copies of deployment and database for each editor.[/quote]
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]For algorithms, table looks amazing. Until the user types fib(MAX_INT). Or Acekrman(4,4).[/quote]
And then our tool displays "infinite recursion", or some such. Better to provide UI for finite cases, than not at all.

[quote]Not with languages we have. Consider this:[code]template < size_t N > struct OptimizedTexture { int getWidth() { return N; } }[/code] 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.[/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]A system [url="http://en.wikipedia.org/wiki/Lisp_machine"]like that exists[/url]. (insert obligatory comment about Lisp doing it before everyone).[/quote]
It's a Turing machine, we get it. But quite frankly, whether in software or hardware, a Turing machine is still a Turing machine.

[quote]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.[/quote]
Just as well I didn't suggest a fully introspective system then. Our little sandbox allows us to examine the contents of memory, and replay functions with varying inputs - all you need for any of the items shown in the video.

[quote]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.[/quote]
Wow. You've exceeded even my tolerance for jaded old-timer ranting. I'm going to say good night...

Share this post


Link to post
Share on other sites
Antheus    2409
[quote]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]

[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.

[quote]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".

[quote]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.

Share this post


Link to post
Share on other sites
swiftcoder    18426
[quote name='Antheus' timestamp='1329920682' post='4915495']
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?[/quote]
Certain data sources/sinks are immutable - that's a given. Pretty much anything that comes from outside the source code, in fact.

You change a parameter relating to an immutable source/sink, and you get an error/undefined behaviour (exactly as happens if you make the same change today). The only difference is that this error message pops up as you work, rather than in a separate compilation step.
[quote]To determine whether it's finite or infinite, you need to solve halting problem.[/quote]
Of course it isn't possible to find the limit in the general case, but it's simple enough to cap our tool at 100 stack frames, or 100 bytecode instructions, or whatever arbitrary criteria proves reasonable.

However, I'm not advocating for a generalised solution. A practical solution for a limited subset of problems is perfectly acceptable to me.

I'd like the ability to tweak constants at runtime, and this is eminently achievable. Hell, there's even a [url="http://www.gamedev.net/page/resources/_/technical/game-programming/tweakable-constants-r2731"]GDNet article that manages to set that up in C++ using some unholy macros[/url]. 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. That's trivial to do with a scripting language, and certainly not impossible to do with a compiled language. Obviously it only is of benefit in a certain class of algorithm development, but that's a lot better than nothing...

Share this post


Link to post
Share on other sites
Antheus    2409
[quote]I'd like the ability to tweak constants at runtime, and this is eminently achievable. Hell, there's even a [url="../../page/resources/_/technical/game-programming/tweakable-constants-r2731"]GDNet article that manages to set that up in C++ using some unholy macros[/url]. 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? [code]x86mov.prototype.write = function() { ... }[/code]
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.

Share this post


Link to post
Share on other sites
Hodgman    51222
[quote name='Antheus' timestamp='1329920682' post='4915495']You asked why nobody is building tools like that.
Because we can't.[/quote]No, actually, we do. In every (good) video game engine, we do build tools like this.
If you can't edit content (code+data) and immediately see the new results on your screen, then your game engine needs an upgrade.

However, if you interpret the aim of such tools to be as general and broad and impossible as you can, then yes, you're right, it's definitely unpossible. Any time anyone brings up the halting problem, they're probably off in some academic la-la land instead of actually doing something useful in reality, like upgrading my damn game engine so I can see what I'm doing.

Share this post


Link to post
Share on other sites
Antheus    2409
[quote name='Hodgman' timestamp='1329956280' post='4915711']
[quote name='Antheus' timestamp='1329920682' post='4915495']You asked why nobody is building tools like that.
Because we can't.[/quote]No, actually, we do. In every (good) video game engine, we do build tools like this.
If you can't edit content (code+data) and immediately see the new results on your screen, then your game engine needs an upgrade.[/quote]

But you need to build the tool that will fit into whichever project you're currently building. You don't have a tool first, then as you go along, it shapes the result. That's the idea behind these concepts.

An engine inevitably limits you to whatever it was designed for. Compare this to tree concept, which starts as bunch of lines, then experimentally moves into day/night scenery of a tree in wind.

[quote]instead of actually doing something useful in reality, like upgrading my damn game engine so I can see what I'm doing.[/quote]
There are more articles from same author, including one of them mentioning the reason for these experiments.

As long as designer (whoever) needs to call onto a developer to do a tweak or do some technical bit, there's a huge impediment to creativity. Pipe dream goal of such experiments is to present tools that vanish out of sight.

In the same way one no longer needs a programmer to read mail, write docs or edit spreadsheets.

Imagine writer trying to write a new book using some text editor:
W: "I'm trying to present John as sarcastic, but the paragraph keeps breaking"
P: "Yea, the TLB is getting messed up, you've only got 4GB of RAM"
W: "Can you fix it?"
P: "Well, I could work around it if you reduce allegory to only 2 pages"
W: "But those sections define the premise"
P: "Could you rework the childhood suffering motive?"
W: "..."

Text editing is a blank canvas which doesn't limit the content written. But existing programming tools do, or at very least, we've exhausted creative potential they can realize. It's less that we cannot do interesting things with them, it's that the reach has plateaued.

Share this post


Link to post
Share on other sites
Hodgman    51222
[quote name='Antheus' timestamp='1330005982' post='4915861']An engine inevitably limits you to whatever it was designed for. Compare this to tree concept, which starts as bunch of lines, then experimentally moves into day/night scenery of a tree in wind.[/quote]No, the tree demonstration would map exactly as is onto a modern game engine. One viewport shows you your scene, the other shows you the design behind the scene, which you can tweak with realtime feedback. Playing with these controls leads to discovery.[quote]As long as designer (whoever) needs to call onto a developer to do a tweak or do some technical bit, there's a huge impediment to creativity. Pipe dream goal of such experiments is to present tools that vanish out of sight.[/quote]Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all!

Share this post


Link to post
Share on other sites
Sirisian    2263
Just watched that video. The circuit editor is the most impressive thing. As someone that's tried to design an analog circuit he perfectly captures how complex it is to visualize the effects of small changes to a design. Especially if you compare it to what the market has for analog circuit editors which look like 1994 VB6 applications.

Share this post


Link to post
Share on other sites
way2lazy2care    790
[quote name='Hodgman' timestamp='1330055724' post='4916092']
Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all!
[/quote]

Just a note, but doesn't Unreal let you change/tweak most everything in at least some runtime sense? I don't think you can edit the full game at runtime, but stuff like art I believe can be shown in engine as you are editing it iirc. I think it's also pretty trivial to hop into any point in a game to test while you edit (one button I think?). I'd assume CryEngine is similar, but have no experience with it. I know runtime tweaking of existing gameplay behavior is nothing taboo in the projects I've been on outside these two engine's as well--maybe underutilized, but the functionality has been there.

Looking back it seems like the problems he's talking about, while flashy, are already somewhat solved. It almost sounds like, "I'm going to make a tech demo of a less fully featured version of Unreal Kismet and brand it as my own innovation."

Share this post


Link to post
Share on other sites
Antheus    2409
[quote name='Hodgman' timestamp='1330055724' post='4916092']
Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all![/quote]

Where is my[url="http://www.youtube.com/watch?v=LpfmKIxusZY"] time traveling debugger then[/url]? Just like the guy moves forward and backward, where's a tool for that? Because that idea didn't exist until a few years ago, whether in games or elsewhere and has since been patented into oblivion.

Of course purpose-specific tools have been built since day 1. Presentation is more about further reaching ideas, about concepts that really are not available today.

And considering I do have all the latest tools, I don't see anything that has moved even an inch beyond the Turbo Pascal era of tooling. But apparently, VS 2011 will be gray instead of purple?

Obviously, I can built something myself, from scratch, specifically tailored to specific problem being solved. There is definitely an incredibly advanced tree editor. But it was and always will be nothing but a tree editor. Very useful, proven in day-to-day, but still just a tree editor.

Nobody is denying that increased hardware power made dynamic programming more accessible or that specific domains have state-of-the-art tools. Ironically, programming has always been about dynamic and interpreted languages, there was just a brief phase where compiled languages offer sufficient performance edge to dominate.

Experiments like these are more about thought process that long transcends the notion of tool itself. Just like there is a universal compiler instead of one being forced to build one specifically for each individual project, or one focused on tiny subsections of problems.

Whether they're useful or not will more depend on individual project. True creativity is in very short demand these days.

[quote]The circuit editor is the most impressive thing.[/quote]

[url="http://worrydream.com/"]Tons of other examples[/url], including further reasoning behind experiments.

Based on those, the guy started thinking about these concepts while working for Apple, where he realized designers were constrained by tools and still depended on programmers. I'd doubt that Apple of all things has problems keeping up with latest and greatest when it comes to design, prototyping or production. Thought it doesn't necessarily mean those experiences transfer to every other domain.

Share this post


Link to post
Share on other sites
way2lazy2care    790
[quote name='Antheus' timestamp='1330094428' post='4916210']
There is definitely an incredibly advanced tree editor. But it was and always will be nothing but a tree editor. Very useful, proven in day-to-day, but still just a tree editor.
[/quote]
It's not a tree editor. It's a rectangle, multiple splotchy circle, jagged line, single large circle editor that happens to also be able to make a tree with mountains/moon.

[img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img]

Share this post


Link to post
Share on other sites
Antheus    2409
[quote name='way2lazy2care' timestamp='1330095847' post='4916216']
It's not a tree editor. It's a rectangle, multiple splotchy circle, jagged line, single large circle editor that happens to also be able to make a tree with mountains/moon.
[/quote]

I was referring to SpeedTree or equivalent modules. Vastly superior to the demo, but in idea just a tree editor, built with disproportionate effort over past 10 years.

The demonstration suggests equivalent free form tool.

Kinda like the old spice guy. Look up, it's a tree, look down, now it's lines, look back up, it's waving in the wind. It's night. Now it's day.

Share this post


Link to post
Share on other sites
MarkS    3502
[quote name='Sirisian' timestamp='1330064228' post='4916114']
Just watched that video. The circuit editor is the most impressive thing. As someone that's tried to design an analog circuit he perfectly captures how complex it is to visualize the effects of small changes to a design. Especially if you compare it to what the market has for analog circuit editors which look like 1994 VB6 applications.
[/quote]

There are programs like Spice that do circuit simulations already, although I do like his graphical waveform representation. However, some of his comments lead me to believe that he doesn't understand the purpose of a schematic. The symbols are there to show how the components connect together, not merely as a means of drawing a circuit on paper. I could take that schematic, and without knowing its purpose or how it works, get the components, wire them together and the design will (hopefully) work as the designer intended. His resulting "schematic" is all but useless. If I were trying to make a PCB out of that, I wouldn't know where to start!

Share this post


Link to post
Share on other sites
ddn3    1610
Such a free form tool which encompasses the ideas of immediate feedback, reversible execution, built in execution safety nets like memory overruns, infinite loops, in execution memory modification etc.. Is it really needed? It's nice in theory but do people think or develop in such a fashion? It's a like sandbox for programs for programmers, but every example he shows, is example of a pre-solved system after which u then apply foresight into the problem space and then expand upon the exist solution through the use of selective paramaterzaion, customized input and output..

That's nice but it requires foresight into the soultion space after the fact. I'm not sure how others come about with their software solutions but for me, program space is too large to just mess around with a bunch of parameters to come up with a solution ,( for humans anyways, a machine learning algorithm is another thing all together ). Even a trivial problem expands with recombination, beyond human comprehension. You will still need insight to guide those random walks to produce anything eventful, imo..

I think UI is very important and is the limiting factor for most systems but I don't think creating a open ended sand box for programs for programmers, is the answer. I'm not even sure what was the question.

-ddn

Share this post


Link to post
Share on other sites
shurcool    439
Such an incredible, excellent and inspiring talk, and I'm at a loss for better words. Thanks so much for sharing! I saw this on twitter, but didn't get a chance to see it cuz of 1 hour length. I wish I knew watching the first 7 minutes would be enough (to understand that you must see everything).

I really like his approach to life, and I'm attempting to do something similar.

[quote name='way2lazy2care' timestamp='1329748110' post='4914815']
I think a large point he makes that's overshadowed with his demo is how little progress has been made toward making a language that's more inline with current UI developments than text editing. I think a more visual language could be pretty interesting. To my knowledge there aren't any (good) low level visual programming languages yet?

I do think that his code editing visualizer could break down in more complex cases. It's pretty simple to handle functions more in line with functional programming, but I feel like it would either be unusably slow or just broken in more complex cases when there is a little more dependency on external data.
[/quote]

I'm actually [url="https://twitter.com/#!/shurcooL/status/173110768726839296"]working[/url] on one right now. I started a few weeks ago, so it's very early without much to show yet, but I'll see how it goes.

I'm doing it precisely because I believe there is potential in the area (after all, if you remove your restrictions, such as code must be "plain text", then you should be able to achieve at least as much or more, right?), and I didn't see any existing solutions. I'm making something I want to use myself, and if it's good I'm sure others would want to also.

[quote name='Antheus' timestamp='1330094428' post='4916210']
And considering I do have all the latest tools, I don't see anything that has moved even an inch beyond the Turbo Pascal era of tooling. But apparently, VS 2011 will be gray instead of purple?[/quote]
Don't forget the achievements.

To be fair, there are actually some very nice incremental improvements in VS 11. I'd say more so going from 2010 to 11 than 2008 to 2010. And I think VS needs to exist, because it fulfills a specific purpose for the time being, and cannot be replaced instantly. But I believe there should be work done on alternative approaches, and perhaps they can one day overshadow VS (if they're good enough).

Where is the time-travelling debugger though? We need to have that asap please.

Share this post


Link to post
Share on other sites
shurcool    439
Actually, I just found a project that does something very similar to what I was about to build, Code Bubbles.

It seems it branched off into an experimental thing at Microsoft for Visual Studio named Debugger Canvas.

[url="http://msdn.microsoft.com/en-us/devlabs/debuggercanvas"]http://msdn.microsoft.com/en-us/devlabs/debuggercanvas[/url]

Check out the video at the bottom. Very cool!

Share this post


Link to post
Share on other sites
shurcool    439
[quote name='shurcool' timestamp='1330226100' post='4916642']
Where is the time-travelling debugger though? We need to have that asap please.
[/quote]
Hmm, is this it?

[img]http://img221.imageshack.us/img221/466/imageur.png[/img]

[url="http://www.microsoft.com/visualstudio/11/en-us/products/compare"]http://www.microsoft.com/visualstudio/11/en-us/products/compare[/url]

Share this post


Link to post
Share on other sites
Antheus    2409
[quote name='shurcool' timestamp='1330537191' post='4917848']
Hmm, is this it?
[/quote]

To a degree.

Now extrapolate this into fictional territory.

User submits a bug. You click a button and end up with their application state. You move forward and backward to diagnose that.

Not inside debugging session, but regular user, perhaps visiting a website or running an app. Doesn't really matter, the concept of "application" or "exe" is not all that important anymore, one gets a snapshot of user's workflow and all that affects it, be it current process, driver, OS, hardware.


Debugging history today is limited to capturing a small set of events inside a specially crafted debugging session. It works with limited set of managed languages which can establish such a separation.


But more on topic of direct modification of application (or game) state. Debugging crashes is still a pain. Rather than focusing on technical widgets, imagine usability only. When a user experiences an issue (not necessarily a crash), they may opt to send the application state directly. No more bug trackers, filling out issues, writing "steps to reproduce". They simply say "the button should not be here".

As developer, you receive such issue, then just move a bit back or forth through execution to pin point the error.

Next, there's diagnosis tools. Mark a logical item in such application snapshot, "find all references" to see how it got into that state (when was button.visible set to true). This isn't manual reference chasing, but automated analysis of program flow. Most of this type of programming is nothing but reference chasing. A very manual task for majority of part.


A tool like this could be built, but only given sufficient hardware and even then it would be pushing everything, from storage to computational capacity.

We have small and limited tools that help with individual parts of the process, but not the next step. Just like 20 years ago building a dictionary was a considerable technical challenge due to hardware constraints, it's trivial today (set<String>).

Hence I mentioned the unpopular CS topics which do hint that such tools will likely never be possible or that a particular step will become possible in a given number of years when hardware advances to the point where problems we're solving are smaller than that.

Instead of P vs. NP, it's closer to economy and exponential growth. For most human endaevors, there is an upper limit. Dictionary has finite size and hardware outgrew that. Maybe we'll reach an upper limit on computer-assisted tasks as well.

Share this post


Link to post
Share on other sites
Hodgman    51222
[quote name='Antheus' timestamp='1330539027' post='4917867']Now extrapolate this into fictional territory.[/quote]That's not fiction - that's modern debugging...
[quote]User submits a bug. You click a button and end up with their application state. You move forward and backward to diagnose that.
Not inside debugging session, but regular user, running an app. One gets a snapshot of user's workflow and all that affects it, be it current process, driver, OS, hardware.
When a user experiences an issue (not necessarily a crash), they may opt to send the application state directly. No more bug trackers, filling out issues, writing "steps to reproduce". They simply say "the button should not be here".[/quote]This has been mainstream for 10 years now...
[quote]Debugging history today is limited to capturing a small set of events inside a specially crafted debugging session. It works with limited set of managed languages which can establish such a separation.[/quote]No it's not -- in a modern C/C++ game engine, from when the user starts the game to when they encounter a bug, every frame of their entire session can be reported and analysed (and imported into a "special debugging session" if required).
[quote]But more on topic of direct modification of application (or game) state. Debugging crashes is still a pain.
As developer, you receive such issue, then just move a bit back or forth through execution to pin point the error.[/quote]We can do this easily these days. Modern game engines need to support NUMA architectures, which means the lowest levels operate on the "input->process->output" black box concept. Inputs and outputs are buffers, and processes are scheduled so they only run at safe times.
At any time, you know exactly what buffers are potentially being read or written (global state is dead). Furthermore, before/after each process, you can store the state of any mutable buffers, allowing perfect rewind functionality.
When the user submits an issue, you can use the submitted replay to end up in the problematic state (deterministic replay of the user's session) and then rewind/replay to find the cause / bug. This is real and is easy to implement, not some far-fetched impossible idea.
[quote]Next, there's diagnosis tools. Mark a logical item in such application snapshot, "find all references" to see how it got into that state (when was button.visible set to true). This isn't manual reference chasing, but automated analysis of program flow. Most of this type of programming is nothing but reference chasing. A very manual task for majority of part.[/quote]We've had tools to automate this for a long time. Both for general reference-chasing, and for change-detection.
[quote]A tool like this could be built, but only given sufficient hardware and even then it would be pushing everything, from storage to computational capacity.
Hence I mentioned the unpopular CS topics which do hint that such tools will likely never be possible or that a particular step will become possible in a given number of years when hardware advances to the point where problems we're solving are smaller than that.[/quote]Uh, no. Get with the times, grandpa. This shit is real.

Share this post


Link to post
Share on other sites
Antheus    2409
[quote]in a modern C/C++ game engine[/quote]

I'm not talking about game engines or C/C++.

I'm typing this in Firefox. How do I click a button to send you current state of my application so you can stack trace it. While you're at it, fix the DX bug which causes corruption when I resize google maps at over 1024 width (here, I opened the problem page in another window, look at the computer state to find out if it's a driver or application bug)

Because for me, just building FF takes 2 hours and breaking to enter debugger and load symbols at a single point takes 15 seconds.

What am I missing here?

[quote]We can do this easily these days.[/quote]

OK. Why aren't you making billions with it and collect Turing prize for it? Because tool like that would be revolutionary. Why doesn't anyone know about this? Why do you let others file patents if its so trivial and a done deal?

Is it possible we're talking about something different?

Share this post


Link to post
Share on other sites
swiftcoder    18426
[quote name='Antheus' timestamp='1330616168' post='4918207']
I'm typing this in Firefox. How do I click a button to send you current state of my application so you can stack trace it.[/quote]
Worth pointing out that this is pretty trivial in any language with serialisable continuations. Plus, somebody [url="http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-between-images-with-fuel/"]has actually implemented it in SmallTalk[/url].

Share this post


Link to post
Share on other sites
Antheus    2409
[quote name='swiftcoder' timestamp='1330678753' post='4918525']
Worth pointing out that this is pretty trivial in any language with serialisable continuations. Plus, somebody [url="http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-between-images-with-fuel/"]has actually implemented it in SmallTalk[/url].
[/quote]
Apparently, Smalltalk is for grampas, while the cool kids are doing this today with everything.

But it doesn't answer my original question - if this has been a solved problem for 10 years, where is button to do that when I'm debugging Firefox and driver issues running on Windows?

But the thread has come full circle back to my original claim. The design of OSes and other components solidified around proprietary blobs, making development of such tools impossible at any meaningful scale, which is why interest and research, academic or otherwise died down.

Small steps are being made within sandboxes (CLR, JVM, JS engines), but these are still a far cry from stuff that was already done decades ago.


It's also why I feel presentations like this are important. Even if they don't show anything that is technically new, they remind about ideas. Telling someone to go learn Smalltalk won't produce results. But showing a tool like that makes people ask why we don't have stuff like that already may cause them to discover not just that, but also other technologies and different approaches. And it sparks interest into more than just banging out some API calls with Vendor Tool 2012.

Node.js and NoSql, the two most overhyped words recently aren't new or even innovative. But they revived some old ideas in practical form available to developers who do not want or cannot reason about underlying scientific and engineering aspects of concurrency theory, yet use these tools to great effect for actual value in their work. What was once constrained by tool no longer is. Dissemination of ideas and interest is much more important than siloed pinnacles of knowledge.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this