[fonc] Formation of Noctivagous, Inc.
In the process of learning programming to form Noctivagous, Inc. I came to question fundamental computing science, specifically how the programs are laid out. I am, however, interested in anyone who wishes to work on my newest project, 1draw33, which I announced first on the FONC list, in 2012. The website, if people are interested, is http://noctivagous.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Personal Programming Environment as Extension of Self
On Sat, Sep 21, 2013 at 6:01 AM, Matt McLelland mclelland.m...@gmail.comwrote: The artifact being constructed in a naive image editor is an image and it's not particularly fruitful to view that image as a program. It's very fruitful! An image could be interpreted as a high level world-map to support procedural generation with colors indicating terrain types and heights. Or the image could be interpreted as a template for a cellular automaton. And, of course, the image could be a simple icon or texture. Granted, I can't think of many uses for *raster* images. But if we extend this to the broader concept of image artifacts - diagrams, graphs, and so on there are many effective ways to interpret them as programs. There's a whole bunch of low-hanging fruit here. Don't let go to waste. As you're saying, you can view the operations of building an image as defining a programming language and more advanced image editors show you a pipeline of such operations and let you edit it in ways that are starting to feel like programming. But when you look at things that way, the image is not the program -- the pipeline is the program. The pipeline is ALSO a program, and a much more implicit one. Every user action is an act of *meta*-programming. Every artifact has behind it history of actions associated with its construction. If relevant parts of this history can be extracted, perhaps tuned a little for reuse, then developers can build many useful tools without ever explicitly thinking about it as programming. And the best way to look at and understand that pipeline is probably structured text. Think of how the pipeline is usually presented: a stack of text descriptions of each operation (probably combined with a thumbnail of the image after that stage). I think structured text - in particular, a tacit concatenative program - is a great way to *formally* understand the pipeline. Having this structure is essential. It enables formal approaches to extracting and delimiting the history associated with an artifact. Irrelevant actions (anything not contributing to the artifact's value or type) can be eliminated. I would want the formal descriptions to also be there, kind of omnipresent in the background (like formula in a spreadsheet), if only so that regular users learn a little by osmosis and curious fiddling. As I said, programming should be basic computer literacy. But I think presenting the pipeline would often be done in other terms of informal text (e.g. output of an explain method), in addition to the icons. (cf. Bret Victor's Drawing Dynamic Visualizations - http://vimeo.com/66085662). We can consider an arbitrary UI to be building a program, but you aren't really programming unless you're interested in the whole program at once. Users should be enabled to: * easily think in terms of capabilities not apps * extract and tune action into reusable tools * organize, maintain, and share sets of tools * easily compose tools when they wish * understand artifacts as long-running behavior * manipulate artifacts as acts of live programming * treat artifact manipulation as UI widgets There is no the whole program, just myriad composable, sharable subprograms. What you today call real programming should be looked at in hindsight as caveman programming - i.e. those dark ages when programmers huddled into dank caverns and cubicles with a keyboard and monitor and those ancient towers rather than the ubiquitous, augmented reality. Much like we regard assembly language programming today. Related: http://xkcd.com/378/ The environment should help users a great deal: * pattern recognition, programming-by-example * automatic example-input generation for testing and tuning * automatic search, genetic programming * Markov models to unobtrusively predict user action Visualization is not the only area where tacit concatenative helps a great deal. while this is really just terminology we're hammering out, I would prefer to say that 95% of UI users aren't programming. Programming is when you care about the whole program. To understand users as programmers - the 95% case - isn't just terminology. It's a new way of thinking. A new perspective can be extremely valuable. As a concrete example, a recent physics articlehttps://www.simonsfoundation.org/quanta/20130917-a-jewel-at-the-heart-of-quantum-physics/ describes quantum interactions as a higher-dimensional timeless geometry. By doing so, it computes on a napkin interactions that took hundreds of pages with Feynman diagrams. To perceive users as programmers seems, to me, just as valuable for simplifying PL as that quantum jewel is for physics. I ask that you reconsider your current views, and whether what you call 'real programming' has real intrinsic value. So now consider the special case where the UI we're interacting with is an IDE Why should this be a special case? The user environment I described is always an IDE. With a much broader 'I'.
Re: [fonc] Formation of Noctivagous, Inc.
Can you change the font on that website? My eyes are bleeding. On Sat, Sep 21, 2013 at 9:49 AM, John Pratt jpra...@gmail.com wrote: In the process of learning programming to form Noctivagous, Inc. I came to question fundamental computing science, specifically how the programs are laid out. I am, however, interested in anyone who wishes to work on my newest project, 1draw33, which I announced first on the FONC list, in 2012. The website, if people are interested, is http://noctivagous.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Formation of Noctivagous, Inc.
Considering that you didn't even comment on what the website is before criticizing it, I don't give a fuck if your eyes bleed. On Sep 21, 2013, at 12:56 PM, David Barbour wrote: Can you change the font on that website? My eyes are bleeding. On Sat, Sep 21, 2013 at 9:49 AM, John Pratt jpra...@gmail.com wrote: In the process of learning programming to form Noctivagous, Inc. I came to question fundamental computing science, specifically how the programs are laid out. I am, however, interested in anyone who wishes to work on my newest project, 1draw33, which I announced first on the FONC list, in 2012. The website, if people are interested, is http://noctivagous.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Personal Programming Environment as Extension of Self
On Sat, Sep 21, 2013 at 12:29 PM, Matt McLelland mclelland.m...@gmail.comwrote: 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 , 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 Yellowhttp://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 DD-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
Re: [fonc] Personal Programming Environment as Extension of Self
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 dmbarb...@gmail.com wrote: On Sat, Sep 21, 2013 at 12:29 PM, Matt McLelland mclelland.m...@gmail.com 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 , 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 Yellowhttp://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 DD-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
