David, Great Writeup. To get down to more practical terms for laymen software engineers such as myself, what can we do in immediate terms to realize your vision?
I'm a big believer in tools( even though I'm installing emacs 24 and live-tool). Is there currently a rich IDE environment core in which we can start exploring visualization tools? Here's what I'm getting at. We have rich IDEs (in relative terms), Intellij, Resharper, VS, Eclipse, whatever.. I think they are still very archaic in programmer productivity. The problem I see is that we have a dichotomy with scripting ennviroments (Emacs) as opposed to "heavy" IDEs. e.g. we can't easily script these IDEs for expermination. thought? On Sat, Sep 21, 2013 at 5:34 PM, David Barbour <[email protected]> wrote: > On Sat, Sep 21, 2013 at 12:29 PM, Matt McLelland <[email protected] > > wrote: > >> > An image could be interpreted as a high level world-map to support >> procedural generation with colors indicating terrain types and heights. >> >> This is common practice in games, but it doesn't IMO make artists into >> programmers and it doesn't make the image into a program. >> > > Not by itself, I agree. Just like one hair on the chin doesn't make a > beard, or one telephone doesn't make a social network. > > But scale it up! One artist will eventually have dozens or hundreds of > data-objects representing different activities and interacting. In a > carefully designed environment, the relationships between these objects > also become accessible for observation, influence, and extension. > > The only practical difference between what you're calling an 'artist' vs. > 'programmer' is scale. And, really, it's your vision of an artist's role > that's failing to scale, not the artist's vision. Artists are certainly > prepared to act as programmers if it means freedom to do their work (cf. > Unreal Kismet, or vvvv, for example). But they have this important > requirement that is not well addressed by most languages today: immediate > feedback, concreteness. > > A team of artists can easily build systems with tens of thousands of > interactions, at which point they'll face all the problems a team of > programmers do. It is essential that they have better tools to modularize, > visualize, understand, and address these problems than do programmers > today. > > >> >> I think there is a useful distinction between user and programmer that >> should be maintained. >> > > I think there should be a fuzzy continuum, no clear distinction. Sometimes > artists are more involved with concrete direct manipulations, sometimes > more involved with reuse or tooling, with smooth transitions between one > role and the other. No great gaps or barriers. > > Do you have any convincing arguments for maintaining a clear distinction? > What precisely is useful about it? > > > > How can you view playing a game of Quake as programming? what's to be >> gained? >> > > Quake is a game with very simple and immutable mechanics. The act of > playing Quake does not alter the Quake world in any interesting ways. > Therefore, we would not develop a very interesting artifact-layer program. > There would, however, be an implicit program developed by the act of > playing Quake: navigation, aiming, shooting. This implicit program would at > least be useful for developing action-scripts and Quake-bots so you can > cheat your way to the top. (If you aren't cheating, you aren't trying. :) > > If you had a more mutable game world - e.g. Minecraft, Lemmings, Little > Big Planet 2, or even Pokemon > Yellow<http://aurellem.org/vba-clojure/html/total-control.html> - > then there is much more to gain by comprehending playing as programming, > since you can model interesting systems. The same is true for games > involving a lot of micromanagement: tower defense, city simulators, > real-time tactics and strategy. You could shift easily from micromanagement > to 'programming' higher level strategies. > > Further, I believe there are many, many games we haven't been able to > implement effectively: real-time dungeon-mastering for D&D-like games, for > example, and the sort of live story-play children tend to perform - > changing the rules on-the-fly while swishing and swooping with dolls and > dinosaurs. There are whole classes of games we can't easily imagine today > because the tools for realizing them are awful and inaccessible to those > with the vision. > > To comprehend user interaction as programming opens opportunities even for > games. > > Of course, if you just want to play, you can do that. > > >> >> I find myself agreeing with most of your intermediate reasoning and then >> failing to understand the jump to the conclusion of tactic concatenative >> programming and the appeal of viewing user interfaces as programs. >> > > Tacit concatenative makes it all work smoothly. > > TC is very effective for: > * automatic visualization and animation > * streaming programs > * pattern detection (simple matching) > * simple rewrite rules > * search-based code generation > * Markov model predictions (user anticipation) > * genetic programming and tuning > * typesafe dataflow for linear or modal > > Individually, each of these may look like an incremental improvement that > could be achieved without TC. > > You CAN get automatic visualization and animation with names, it's just > more difficult (no clear move vs. copy, and values held by names don't have > a clear location other than the text). You CAN do pattern recognition and > rewriting with names, it's just more difficult (TC can easily use regular > expressions). You CAN analyze for linear safety using names, it's just more > difficult (need to track names and scopes). You CAN predict actions using > names, it's just more difficult (machine-learning, Markov models, etc. are > very syntax/structure oriented). You CAN search logically for applicative > code or use genetic programming, it's just freakishly more difficult (a lot > more invalid or irrelevant syntax to search). You CAN stream applicative > code, it's just more difficult (dealing with scopes, namespaces). > > But every little point, every little bit of complexity, adds up, pushing > the system beyond viable accessibility and usability thresholds. > > Further, these aren't "little" points, and TC is not just "marginally" > more effective. Visualization and animation are extremely important. > Predicting and anticipating user actions is highly valuable. Code > extraction from history, programming by example, then tuning and optimizing > this code from history are essential. Streaming commands is the very > foundation. > > Stop cherry-picking your arguments; you've lost sight of the bigger > picture, or maybe you haven't glimpsed it yet. Step back. Try to address > ALL these points, simultaneously, in one system, while *keeping it simple*. > If you can do so with a named applicative model, I'll be impressed and > interested. > > >> I will occasionally have to give you an error message "usage of name is >> illegal in this context", right? For example, violates substructural >> types. I still count that as an easy translation >> > > Under your proposal, the safety property is no longer compositional, no > longer correct-by-construction (i.e. requiring only syntactically local > analysis to validate); it now requires a non-local post-hoc analysis (not > an easy one, if you do any sort of inference). And while this might not > seem important for the concerns you've been tracking so far, I ask you to > review how this might affect streaming, local rewrites, and similar. > > You call it an 'easy' translation. I call it a 'lossy' translation. > > Or perhaps a more fitting phrase is: trying to put the toothpaste back in > the tube. > > >> >> most of your ideas sound pretty good to me, but I think there are a >> couple of sticking points that I'm still not on board with. I'm certainly >> open to the possibility that I just haven't gotten it yet, and either way I >> wish you the best of luck in getting your system going. >> > > Thanks. I imagine most people would be less open, more dismissive, and I > appreciate how you've engaged me on this so far. > > Warm Regards, > > Dave > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
