Created by Ubi de Feo, “from 0 to C” is a series of workshops that aim to teach programming using a tangible approach. Learning how to program requires pragmatic thinking and “advanced problem solving” and through the use of tangible, hand-made objects, the team behind the project try to establish a clear understanding of how a computer works and what a programming language actually is.
With the increase of interest in coding, trying to sometimes teach programming to designers can indeed be a challenging task. There are many tools available already that CAN readers are very familiar with. Aimed primarily at designers, Design by Numbers, Processing, openFrameworks and most recently Cinder are all frameworks designed to create a bridge between complicated layers of code into easier to understand and apply scenarios. To those learning these tools, it is often that difficulties arise even before the creative process begins. This could partially be blamed on the lack of understanding underlying principles of how computer works and the logic of programming languages.
The concept of “from 0 to C” is simple: take a bunch of common tangible objects and organic materials such like M&Ms, Ping-Pong balls and wood, mix them with a group of non-experts willing to learn how to program but not to spend 3+2 years in a computer science university, forget about computer screens and keyboards and bake it for 1, 2 or 5 days (depending on the type of workshop).
From 0 to C’s goal is to create a thorough understanding of what a programming language actually is in terms of the mathematical and logic structure at its core. Making something that initially feels very abstract becoming clearer and more logical.
During the workshop the participants are asked to physically perform tasks involving a subject, an object and an action, and afterwards to rationalise the logic of these sequences in order to translate them in code.
Ubi hopes to take this approach into schools and universities teaching the core basis of programming. I indeed hope so as it seems like a fantastic way to introduce programming. I hope we can get Ubi to Resonate.io next year.
- The Digital Rube Goldberg Processor [Processing] The Digital Rube Goldberg Processor is the outcome of a workshop The Product collective gave at the HfG Karlsruhe (Design School). The team was invited to give a 4-day Processing workshop for the communication design students there. Since they understand it is impossible to teach programming to beginners just within 4 days, they decided to focus more on the essential topics behind generative and computational design, to provide a grounded starting point for the students. Jens explains: We first gave a quick introduction to the processing environment, thematically centered around the actual matter of generative design, namely digital data. Given the fact that any stored data is binary code in the end, it is the encoding and decoding algorithms that make digital data meaningful for us. To create an awareness for that, we came up with the idea of the rube-goldberg-processor (wiki). It is an potentially endless line of sub-processors that transform the same dataset from one state into another. Each group of students had a translate-from-to assignment, e.g. from moving image to sound. To make the steps more comprehensible for observers, the transfer was made in an analog way (camera pointing to monitor, microphone in front of speaker...) In the end, this obvoiusly led to an indecipherable outcome, but on the way, the teams had to negotiate basic "protocols" and concerned themselves with several techniques that are used in computational design. The flickr account in question, website with video and photos The student teams were: Sound to printed patterns: Matthias Gieselmann, Stefanie Miller Moving image to sound: Kirstin Griech, Simon Schelsky Text to image: Nadja Schoch, Lisa Stöckel The Product team provided the first step (image to text) as well as the last step, the flickr uploader. The rest was done by the students. For more teaching by The Product, see the-product.org/category/teaching The Product a berlin-based spatial and media-related design practice. They conceive design concepts. They create installations. They animate surfaces. They design spaces. They develop objects. And they extensively think about the application and combination of technologies in meaningful ways. Text to Graphics Graphics to Sound Sound to Print Print to Flickr Flickr to […]
- Appropriating Interaction Technologies (“Social Hacking”) at ITP AIT (“Social Hacking”), taught for the first time this semester by Lauren McCarthy and Kyle McDonald at NYU’s ITP, explored the structures and systems of social interactions, identity, and self representation as mediated by […]
- Weird Second-order Loops – Generative individuality and circumstance Weird Second-order Loops is a series of computer-generated animation loops that never repeat. Each of the loops is centred around a playful and simple cyclical idea that is a procedural reinterpretation of a long existing animation cliché, potentiating it ad […]
- The HyperCard Legacy [Theory, Mac] In 1963, my dad was looking for a job. Born in England and raised in Africa, he ended up in London after a few years of travel by ship and train. In those pre-pre-Craigslist days, people still searched for employment in newspapers, and an unusual listing in a London Newspaper caught his eye: a listing looking for computer operators. For my father, the listing raised two immediate questions: What is a computer? And how do you operate it? (A similar reaction would have come from job listings for auto mechanics in 1914 or web designers in 1994). Responding to that listing turned out to be a life-changing decision for my dad, who has spent the last 40 years working with computers and technology. A very similar directional moment came for me 24 years later, in 1987, when my dad arrived home from work with a Macintosh SE computer HyperCard, Revisited The Mac SE was actually not as important to my life (and career) as was the software that came with it for free - in particular, an unusual and innovative application called HyperCard. HyperCard was a tool for making tools - Mac users could use Hypercard to build their own mini-programs to balance their taxes, manage sports statistics, make music - all kinds of individualized software that would be useful (or fun) for individual users. These little programs were called stacks, and were built as a system of cards that could be hyperlinked together. Building a HyperCard stack was remarkably easy, and the application quickly developed a devoted following. HyperCard was the brain child of Bill Atkinson, one of Apple's earliest employees, and the software engineer responsible for (among other things) the drop-down menu, the selection tool, and tabbed navigation. Bill played a big role in making the Mac what the Mac was - a personal computer that made the whole process of computing easy for the general public. HyperCard represented perhaps the bravest part of this 'computing for the people' philosophy, as it enabled users to go past the pre-built software that came on the machines, and to program and build software of their own. Assuming that a typical computer would and could learn how to may program seem like a mad idea, but its one that has a long legacy. When personal computers were first envisioned in the 1960s, scenarios included the owners of these machines making their own software. The small group of people who were working in computing probably couldn't imagine why anyone would want a computer if they didn't know how to program it! With HyperCard, the learning process was facilitated by pre-built UI elements, and a simple drag & drop interface. Maybe most important, though, was HyperCard's unique, innovative, and very easy to use programming language, HyperTalk. Say That again, in English? Reading programming instructions written in some languages can be confusing. Statements in HyperTalk, on the other hand, tend to read like sentences in English. For example, if I wanted to create a variable called â€˜nameâ€™ with the string 'bob dole' in it, I would write this: put 'bob dole' into name If I wanted to put the last name into a list of last names that I had already created, I could do this: put the second word of name into last_names And if I wanted to display the name on screen, I would simply write: put name into field 'name_display' This type of plain-language programming makes sense, particularly in an application that was designed specifically for non-programmers. I have been teaching programming to designers and artists for nearly a decade, and I find the largest concern for learners to be not with the conceptual hurdles involved in writing a program, but with obscure and confusing syntax requirements. I would love to be able to teach HyperTalk to my students, as a smooth on-road to more complex languages like Java or ActionScript. HyperTalk wasn't just easy, it was also fairly powerful. Complex object structures could be built to handle complicated tasks, and the base language could be expanded by a variety of available externdal commands and functions (XCMDs and XFCNs, respectively), which were precursors to the modern plug-in. Programming for the People This combination of ease of use and power resonated with the HyperCard user base, who developed and shared thousands of unique stacks (all in a time before the web). A visit to a BBS in the late 80s and early 90s could give a modem-owner access to thousands of unique, often home-made tools and applications. Stacks were made to record basketball statistics, to teach music theory, and to build complex databases. The revolutionary non-linear game Myst first appeared as a HyperCard stack, and the Beatles even got into the scene, with an official stack A Hard Days Night. During the same time, developers made hundreds of extensions. Some let HyperCard stacks talk to other applications on your computer (opening the door to the first computer virus, 'Concept', in 1993). Other let you communicate to the outside world - BeeHive Technology's ADB I/) box was a kind of â€˜Arduino for the 80's, and let stack-makers connect to sensors and send commands to electronics. A large community formed around HyperCard, providing tips & resources as well as a distribution channel for home-brew software makers. The HyperCard Legacy Over the last few years, we've seen many exciting projects that work in the spirit of HyperCard - projects that offer free and simple ways to create custom software tools. Replace the word 'HyperCard' in the paragraphs above with 'Processing' and the word 'stack' with the word'sketch', and many of the innovations and advantages described can be moved 20 years into the future without much of a re-write. HyperCard was the first real hyper-media program, paving the way for the web, and everything that came with it. It was used by thousands of people, and by most accounts, seemed to have been a fairly successful piece of software. Which, of course, begs the question: What happened to HyperCard? A small project in the larger suite of Mac software, HyperCard never really saw the type of development commitment that it would need to remain current as the Mac OS advanced. The small, black-and white application looked more and more antiquated as screens got bigger and more colorful. To compound matters, the project was shuffled back and forth between Mac and its software subsidiary Claris and seemed never to get any kind of sure footing. Though a second version of Hypercard was released in 1990, the project had made few advances since its release five years earlier. Ultimately, HyperCard would disappear from Mac computers by the mid-nineties, eclipsed by web browsers and other applications which it had itself inspired. The last copy of HyperCard was sold by Apple in 2004. The Importance of Middle Ground In new media, practitioners are often identified with the specific tools that they use. I started out as a 'Flash guy' and over the last few years have been connected more and more with the open source software project Processing. Though I originally came to Processing to escape the Flash Player's then sluggish performance, I value the platform as much for its ease of use and its teachability as I do for its ability to quickly add floating point numbers. Lately, I've been asked the same question, over and over again: 'Why don't you move to OpenFrameworks? It's much faster!' It is true that projects built in OF run faster than those built in Processing. This question, though, seems to be missing a key point: faster does not always equal better. Does every pianist want to play the pipe organ because it has more keys? Is a car better than a bicycle? In my case, choosing a platform to work with involves as much consideration to simplicity as it does to complexity. I am an educator, and when I work on a project I am always thinking about how the things that are learned in the process can be packaged and shared with my students and with the public. Which brings us to the broader concept of accessibility. HyperCard effectively disappeared a decade a go, making way for supposedly bigger and better things. But in my mind, the end of HyperCard left a huge gap that desperately needs to be filled - a space for an easy to use, intuitive tool that will once again let average computer users make their own tools. Such a project would have huge benefits for all of us, wether we are artists, educators, entrepreneurs, or enthusiasts. HyperCard, Revisited Over the years, there have been several attempts to revive HyperCard, most recently on the web. TileStack is HyperCard for a social media world, a site in which users can build their own stacks, program them with HyperTalk, and share them with friends. It's a bit of a time capsule, with many classic HyperCard stacks available to satisfy any nostalgic cravings for B&W pixel art you may be harbouring. Unfortunately, HyperCard, as much as we might love it, is 25 years old. These big initiatives to revive it directly end up looking and feeling antiquated. I could imagine a new version of HyperCard being built from the ground up around its core functional properties: HyperTalk, easy to use UI elements, and a framework for extensions. It's the kind of open source project that could happen, but with so much investment already existing in other initiatives such as Processing and OpenFrameworks, it might not be the best use of resources. So, let's forget for now about a resurrection. Instead of thinking bigger, let's think smaller. HyperCard for the iPhone? It might not be as crazy as you think. Imagine having a single, meta app that could be used to make smaller ones. This 'App-Builder App', like HyperCard, could combine easy to use, draggable user interface elements with an intuitive, plain language scripting language. As a quick visit to the App Store will show you, many or most of the apps available today could be built without complex coding. You don't need Objective C to make a stock ticker, or a unit converter, or a fart machine. These home-made apps could be shared and adapted, cross-bred and mutated to create generation after generation of useful (and not so useful programs). By putting the tools of creation into the hands of the broader userbase, we would allow for the creation of ultra-specific personalized apps that, aside from a few exceptions, don't exist today. We'd also get access to a vastly larger creative pool. There are undoubtedly many excellent and innovative ideas out there, in the heads of people who don't (yet) have the programming skills to realize them. The next Myst is waiting to be built, along with countless other novel tools and applications. With the developer restrictions and extreme proprietism of the iPhone App Store, it's hard to remember the Apple of the 80s. Steve Jobs, Bill Atkinson and their team had a vision to not only bring computers to the people, but also to bring computer programming to the public - to make makers out of the masses. At Apple, this philosophy, along with HyperCard seems to have mostly been lost. In the open source community, though, this ideal is alive and well - it may be that by reviving some ideas from the past we might be able to create a HyperCard for the […]
- Social Networking With The Living Dead – Matt Pearson In this social networking microcosm where the living, content generators, the dead, automated bots, spammers all share a peaceful coexistence, Matt Pearson questions his "other" self who speaks his language and says just the kind of things he would […]
- No-one Ever Cried At A Website – Matt Pearson Guest writer Matt Pearson discussed the maturity of code as an artist medium in this first in the series article written for CAN and also published in ebook […]
- Patch Schematics – The Aesthetics of Constraint / Best Practices [Theory] Visual programming languages, languages that create programs by the manipulation of graphical elements, as opposed to specifying lines of text, have seen an increased popularity in recent years both in audio and video synthesis. Some of the more well-known environments, ones that are regularly used for projects that are featured on CAN, include VVVV (real-time motion graphics and physical IO) MAX/MSP (real-time music and multimedia), Pure Data (ostensibly an open source equivalent of MAX/MSP) and Quartz Composer (video synthesis for MAC). Visual programming owes its many of its conventions for the representation of information and programs from Flowcharts - a lesser used term for these kinds of environments is Data-flow Programming. VPL's date back to the late 60's. A good example is the GraIL system (GRaphical Input Language) a flowchart language entered on a graphics tablet developed by the Rand Corporation in 1969. DMX-LED Patches - Kalle Karlen A program (Patch) typically consists of a set of objects (Nodes) that are connected to each other via their inputs and outputs (Pins). In this case I've used the specific terminology of the VVVV environment, but the essentials are the same for other VPLs. The constraints of patch-based visual programming can give rise to some interesting aesthetic configurations. Various factors such as the legitimate connections between nodes, types of information flow paths, the arrangement of input and output devices are some of the constraints that drive the schematic of the patch and the spatialisation of the elements within it. In one sense these kinds of environments could be seen as self-organising systems – where functionality drives local behaviours and interrelationships of nodes and connections. While ruminating over the aesthetics of patches I wondered what were the equivalents (in textual programming) of best practices and programming design patterns and if there were any models? If there were such models being implemented on a wider basis we would see similarities in the schematics in different programmers patches. More so an agreed system of placement of nodes and connections would render patches universally readable by the developer community as a whole. In textual programming there is a long history of best practices, optimisation techniques and standardisation – ways to make the code modular, reusable and manageable over large teams of programmers. Languages such as C++, Java and Actionscript 3 have settled on the Object Orientated Model. Programming Patterns are the paragon of optimisation - ' general and reusable solutions to a commonly occurring problems that 'typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved'. PerfMeter - Kalle Karlen (shows strict top-to-bottom data-flow with horizontal groupings of nodes with similar functions) I talked to some of the VVVV community, as well as some other well-know visual programmers to gain some insight into their preferences for optimisation and the importance of 'visual programming design patterns' if indeed such a thing existed. I've also outlined some of my own personal methods for optimising the layout of patches. Well respected user Kalle Karlen of the VVVV community, who has a VVVV node named after himself, generously sent me screen grabs of many of his patches. Some of his key points were: - The dataflow in the patch should be arranged vertically. - Comments are absolutely necessary if you patch in collaboration with others. - Showing only important pins helps keeping track of data flow. [Pins can be set to zero visibility in VVVV] - A preference not to use curved and VHV (Vertical-Horizontal-Vertical) connectors as design elements until a patch is very close to final perfection – and then only use curved connectors to indicate data feedback loops. Using the GUI to map out a project - Kalle Karlen An interesting additional to Kalle's working method is his his use of the UI to create a block diagram of empty sub patches that act purely as a visual aid in the early planning stage of a project. Joreg, one of the developers behind VVVV, and who was responsible for developing the GUI as part of his diploma thesis also mentioned the importance of using top to bottom data flows. Since visual programming is so much more about data flow than text-based programming languages a clearly discernible top-to-bottom structure for the direction data-flow should be applied. It makes logical sense to have inputs (such as communication with external devices, keyboards and XML) at the top of a patch and outputs (such as a renderer and sound output) at the bottom. In general nodes of a similar function should be aligned on the Y axis. It further makes sense to group nodes that work together in a tight configuration indicating their interrelationships. These groupings can also be considered as possible candidates for subpatches. Nearly everyone I talked said that they would first get the algorithm patched and then, if time permitted, do some re-arrangements to tidy the patch up into a readable format. Eventually any complex patch will outgrow the size of the screen without scrolling the window. In this circumstance it is probably a good time to start thinking about sub-patching especially if a part of the patch can be made into a module and reused in other projects. Joreg mentioned that in VVVV one of the most wanted features is the ability to 'make selected nodes into a subpatch' which would increase the efficiency of modularizing a patch. Parhelia subpatch group - Paul Prudence When a system becomes very complex its often good to implement the finite state machine model to describe the systems state(s) at a particular instant. David Brüll a lead VVVV software designer who usually works with different teams of patchers, programmers and designers on professional projects recommended the use a state designer such as QFSM when planning a patch. He also recommended that all logic related to states of the system to be place in a top level sub-patch. In this sense the structure of a patch might already seem to mimic a design pattern seen in OOP languages (such as MVC) where different aspects of a program are separated and isolated from one another. Semaspace - Woeishi Lean Not everybody works in a rectilinear fashion, and VPL's allow much more liberty in regards to personal style than textual programming. Woeishi Lean works with a dense and extreme clustered style which he says enables him to keep the data flow as exposed as possible. He prefers not to create deep hierarchies of sub-patches as he feel this can cause him to lose the overview of the data flow. 'The main data starts at the upper left and the flow moves down vertically, additional data comes in from the right side. My nodes are often edge on edge and grouped to logical functions so it's easier to grasp all the node names from top to bottom” Video Feedback Loop Patch. In considering the configuration of patches I wondered if there was any examples of isomorphic similarities between spatialisation of elements in a patch and the functionality of patch. One contender for this is the simulation of a recursive function by creating a video feedback loop. Clearly in the above patch you can see a cluster of nodes that generate an 'input', a circuit of renderers which represent the recursive loop (as the 'output' of the renderer is fed-back to another renderer, and so on) and then a final output, as the branch of video-data flow is directed out of the loop to another renderer. 0xA – expr~ (Bass Section) – Chun Lee Moving away from VVVV to PureData we arrive at Chun Lee's lesson in austerity. '0xA – expr~' is musical release, the entirety of which was generated nearly exclusively with one object in PureData, the [expr~] object. The tracks vary from saw-tooth drone to noise systems music all with an 8-bit chip-tune feel. Regarding optimisation Chun had this to say 'I tend not to think of patterns - Pd was never really designed with scalability in mind, so ultimately any effort in trying to enforce some kind of pattern so that codes can be easily reused/organised, would seem a bit like a work around (or too much effort for very little gain)', FastBreeder - Dave Griffiths All thought not written in a VPL environment Dave Griffiths genetic programming synthesizer, FastBreeder, works backwards creating a visual representation of the users 'grown' code structure. The sound generated is therefore related to the structures of the nodes which are automatically generated using an algorithm implementing a form of a nested two-pi layout. Paul Prudence is a audio-visual performer and installation artist working with computational and generative environments. His work, which had been shown internationally, focuses on the ways in which sound, space and form can be combined to create live-cinematic visual-music experiences. Paul maintains the research weblog Dataisnature in which he writes about the interrelationships between natural processes, computational systems and procedural-based art […]
- Indie Game: The Movie – Released Indie Game: The Movie, directed by Lisanne Pajot and James Swirsky, has been released and available for download and your viewing pleasure. The film looks at the underdogs of the video game industry, indie game developers, sharing their lifelong dreams of bringing their visions into life. With the twenty-first century comes a new breed of struggling independent artist: the indie game designer. Refusing to toil for major developers, these innovators independently conceive, design, and program their distinctly personal games in the hope that they, too, may find success. After two years of painstaking work, designer Edmund McMillen and programmer Tommy Refenes await the release of their first major game for Xbox, Super Meat Boy—the adventures of a skinless boy in search of his girlfriend, who is made of bandages. At PAX, a major video-game expo, developer Phil Fish unveils his highly anticipated, four-years-in-the-making FEZ. Jonathan Blow considers beginning a new game after creating Braid, one of the highest-rated games of all time. First-time filmmaking duo Lisanne Pajot and James Swirsky capture the emotional journey of these meticulously obsessive artists who devote their lives to their interactive art. Four developers, three games, and one ultimate goal— to express oneself through a video game. indiegamethemovie.com | Download from iTunes (by James Swirsky | Lisanne […]
Posted on: 11/07/2012
- Senior Digital Designer at CLEVER°FRANKE
- Interaction Designer at Carlo Ratti Associati
- Creative Technologist at Deeplocal
- HTML / CSS Developer at Resn
- Climate Service Data Visualiser at FutureEverything
- Web Developer at &Associates
- Creative Technologist at Rewind FX
- Coder to collaborate with Agnes Chavez
- Data Scientist at Seed Scientific
- Data Engineer at Seed Scientific
- Design Technologist at Seed Scientific
- Creative Technologist, The ZOO at Google