Generative Art will take off when it doesn't require expressing the code through conventional programming language syntax. A visual, interactive programming environment like those advocated by Bret Victor [1] would be ideal for artists without a technical background.
NodeBox, mentioned below, have some characteristics of this, although it doesn't seem to allow the artist to create new abstractions without resorting back to Python.
I don't think that generative art needs to stop requiring programming skills to be successful. The huge community of www.processing.org artists who code suggests this requirement is not a problem. The whole point of generative are is to use programming language as the tool of visual expression as opposed for example to using UI based tools like Photoshop or Illustrator.
Any art (visual or not) requires creators to use various tools and learning these tools takes a lot of time and afford. And mastering them often takes insane amounts of study and practice. Think of work required to learn to sketch human figure well or chisel it out of wood. Think of years of training required to play a violin concerto. Or to dance a ballet piece. Programming is just a new/differnt tool required for creating generative art.
I would even go as far as stating the opposite. Attempting creation of generative art via interfaces other then conventional programming languages is what would limit it! This is for the same reason that professional programmers haven't adopted (not yet at least) visual programming languages - they are too limited in their expressiveness.
The whole interest in generative art and design is driven by the fact that you can create things that you cannot using Adobe (etc...) tools. All the Photoshop and other image creation and editing applications are very powerful, but still limited by the imagination of the people who made them. Creating images using code lets you escape these limitations. This is what makes it an interesting new visual arts discipline.
And if you study lives of many artists you realize that they can be pretty obsessed and determined to work hard to learn tools and techniques in the process of their practice, so I am not worried - there will be many who will become excellent programmers!
What stops fast adoption of this type of art is the educational institutions insistence on separating artists from engineers. If computer science departments offered and occasional art course and fine art departments intro to programming, the generative arts would possibly become one of the most popular art forms in the new century. It would also help more of multidisciplinary creative thinking on both sides. I certainly agree with the article that the possibilities are immense...
Respectfully disagree. I think it's easy for people who have by now built an intuitive grasp of code to appreciate how challenging tools like Processing can be for a beginner.
I have a design background and learned front end code (and eventually ruby on rails) by getting progressively more interested in how the things I was designing were built. I feel like I achieved a pretty respectable level of knowledge in what I had been exposed to.
And yet, many aspects of Processing were a huge leap for me. I spent days looking at code examples just to try and grok how 3D works in processing. I get it now (mostly), but it still feels unintuitive. I can certainly imagine a language that would describe 3D behavior, and a whole host of other things, in a way that a visual artist would describe them.
I definitely believe that there is value in artists learning to think with the rigor that code encourages. It's a fascinating cross-pollination. Creativity often springs from encountering the limits of a medium (and one's mastery of the medium).
But look at the excitement this week among people like me about Swift. It's not about whether it was possible before for me to learn Objective C and build a game. It was. But goddamnit, it's such a pain, and I would certainly understand that someone who is starting from zero in terms of CS knowledge would find it impossibly intimidating.
Design is remarkably accessible. If you can pick up a pen and paper, you can do it. Code is getting way closer to that, but let's not have collective Stockholm syndrome. Our tools are a long way away from where they could be.
Honestly, I wish I had the skills to write a language or build the tools like the ones I can imagine myself. But I have confidence that someone will. It's going to be an exciting time for art, and I think it's coming very soon.
It's a fascinating discussion. Maybe we can meet half way?
> I definitely believe that there is value in artists learning to think with the rigor that code encourages. It's a fascinating cross-pollination...
I agree!
> Design is remarkably accessible...
But this... Well it depends on the point of view. Design can be as intimidating for geeks as programming is for artists.
I have nothing against making programming tools more user or artist friendly. In a sense Photoshop is such a step - it allows many creators make sophisticated images without learning to draw and without learning to program. And certainly many many amazing works were created with it and similar tools.
The point I am trying to make here is that the visual/artistic power or possibilities of generative art and design are very much driven and dependent on the artist's fluency to program. There were many attempts to create programming tools [1] that let you avoid having to slog through typing the code, but seems like none of them would match the expressive possibilities of 'raw' coding and gain any wider adoption. In other words all of them have significant limitations and this would be a step back from the point of view generative artist.
And just to make it clear, I don't think that using any of these higher level tools is wrong or produces works of lesser value. It's just that these works are outside of unique possibilities of generative art driven by traditional coding.
Have you seen the "Stop drawing dead fish" and other Bret Victor talks? Those are not high level tools, they allow you to build generative animation and graphs from scratch.
Photoshop-like visual tools are indeed limited to pre-built concepts, but Victor has found a way to make coding possible without textual syntax; that's a powerful idea that may be the basis for a tool allowing artists to program without requiring the programmer's skill to keep the parse-tree-plus-AST in your head while building automations.
Take a look at the topic of End User Development and Programming by Example[1], it's a quite comprehensive research field dealing with ways that programming-like activities can be done without any traditional "raw coding".
I do! I have some sketches that I drew up a while back. It's sort of a loose collection of thoughts, though this is inspiring me to think about it with more rigor :)
I imagine it as a combination of an abstraction layer on top of processing and a light IDE. Something like a palette of shapes and objects similar to what's available in photoshop and illustrator. Instead of drawing shapes, though, it would create code snippets for the various objects.
Those objects would be available to modify in an event loop similar to Processing (or Arduino, for that matter). With a strong autocomplete for both object names and the available manipulations for those objects, I feel like you could learn just by playing around.
Live preview like Swift /light table etc would be really powerful. Out of the box support for common things like collision detection would be great too. Color pickers that spit out rgba values? Maybe. Basically a tool palette oriented around building code for visuals.
In terms of the language itself, it probably veers more into personal taste. I'd love to see names of things be less arcane /abbreviated. Dropping some of the brackets and parens would be nice for non programmers too. (Again, taste.) Ruby-like syntax for new objects instead of objective-C-like constructors would be more readable. Basically, the more it could just resemble an English description of what you want to happen, the better.
Processing isn't that far away from this description, but the combination of having to refer to the documentation constantly, no sensible defaults, almost limitless customizability, and having to actually compile the sketch to run means that the initial barrier is really high. It's very difficult to get into flow until you reach a high level of familiarity with the language.
I would love to chat about this further and share ideas with you or anyone who's interested!
It seems there's no way to send private messages here at Y Combinator. Send me a mean of contact to twaway00 at gmail if you wish to continue conversation.
The main problem is that programming skill requires a very different skill set than the one usually required to build successful art (insight, a sense of composition and proportions, good taste in colors, all that right-brainy stuff). Although a person may have both, it's rare that someone will be proficient in all those.
People with good visual skills may devote intense learning to the tools of their work, but see how the tools you mention (chisels, violin, proprioception for dancing) don't require strong abstract skills like programming does. Some renaissance men were capable of dominating both forms, but science was way simpler then - and they still gravitated toward graphical representations of structure and theory.
If all generative tools are based on "linguistic" programming based on strong syntax requirements, not allowing a more "intuitive" way to build abstractions, it will remain a highly conceptual form of art. This is still valid art, but quite different from the most popular forms of artistry that people associate with the idea of "art".
Watching Mr. Victor, he tells us about how we're doing old media with new tools (painting, film.) Then he moves on to ... a puppet show using his new tools. I feel like he started with what was going to be an intriguing thesis ("make something new, not just old media with new tools") and changed to building those new tools.
That criticism aside, he's absolutely correct about needing new tools to prevent the creator from needing to learn a programming language. I'd suggest that this is the case in many fields. I'd go so far as to suggest that some day most of us software creators might be able to create software with little to no code, just dragging together concepts. (I'm aware that such tools have existed and do exist. One could argue that they haven't quite nailed it and thus are not very widespread in use.)
(I'm aware that such tools have existed and do exist. One could argue that they haven't quite nailed it and thus are not very widespread in use.)
I believe that day may be closer than you expect. I've seen all, and I mean all the components required to build such a practical programming system. They just were scattered around systems for widely different purposes, or buried in decades-old research projects that were too experimental and heavyweight for the machines available back then. (Victor's is certainly the closer to that vision, although it still misses several key components to make it practical and widespread; a close second is the Wolfram Language).
I have in mind a pet project to combine those partial tools in a way that I think would make a practical mostly-general-purpose programming language. Having some background in human-computer interaction, I think I'd be able to identify the most obvious roadblocks.
Unfortunately, I'm afraid my limited skills and time wouldn't allow my to expand the system beyond a simple proof of concept. If you're interested, I think I could compile a small recollection of my ruminations and put it in a presentable form, if only to inspire others and get some feedback on my approach. I don't know though if that would make for a good Hacker News submission, does this site accept links to personal blogs discussing pet projects?
NodeBox, mentioned below, have some characteristics of this, although it doesn't seem to allow the artist to create new abstractions without resorting back to Python.
[1] in Stop Drawing Dead Fish. http://vimeo.com/64895205