In the less tech-minded circles of digital society (which, lest we forget, comprise its numerical majority), there appear to co-exist two conflicting rhetorics regarding the notion of programming.
The first is, "everyone can program." It is the rhetoric of massively open online courses, and K-12 computer labs, and lively bookstore corners; and what it intimates, essentially, is that programming is the new Literacy,[i] which can greatly expand our capabilities. This is perhaps illustrative of what has been called the “social turn”  in programming. Not only can everyone program, they probably should, because programming empowers you. Programming is no longer a technical skill, it is a social, creative, and expressive one.
The second rhetoric can be summed up as, "you don't need to know how to program anymore," meaning that it is possible to do things previously thought to require programming skills without typing a line of code. Instead, you can rely on various software tools that take care of the technical stuff for you, enabling you to focus on the creative process. We are talking here about a subset of "cultural software" , a term which does not so much denote a particular kind of software but a phase in human history where software does so many things for us it becomes deeply ingrained in cultural production as a whole. Whereas the first rhetoric is, as it were, one of enlightenment, the second is more that of liberation, grounded in the idea of programming as a difficult, obscure, perhaps even elitist activity[ii] －an idea that still seems to have deep roots in the collective psyche of computer users.
Both rhetorics are prominent in the world of videogames. The former is tangible in modding communities and the rise to popularity of such tools as Unity and Flixel, which, while requiring a degree of programming ability, make the developer’s job easier by virtue of being specifically geared towards creating computer games and providing ready-made solutions for many low-level stock routines (graphics rendering, controls, game physics, etc.). The latter rhetoric manifests particularly clearly in “game makers”: computer game creation tools such as Clickteam Fusion, YoyoGames' GameMaker, and Construct 2, which are explicitly advertised as requiring no programming. Consider, for example, the following excerpt from Construct 2's website: “No Programming Required! You can now make advanced games without writing a line of code. Construct 2 does the hard work so you don't have to.”
On the surface, the two rhetorics may seem contradictory. But on a deeper level, they might very well be one and the same. This is perhaps the most obvious when we compare how the notion of “programming” is conceptualized in “game makers” to the interpretation found in various recent digital games that aim to teach children how to program.
Construct 2, like Clickteam Fusion, Game Maker and many other similar tools, enables its users to create their own games by visually arranging pre-defined elements into blocks. Each element has its own function, and the resulting blocks control the behavior of the game. This seemingly straightforward mechanic has enabled independent developers to craft fairly sophisticated works: the Knytt series, the Spirit Engine duology, and The Next Penelope, among many others.
Figure 1. Making a game in GameMaker
Meanwhile, an increasing number of puzzle games (Lightbot, Cargo-Bot, and Bit by Bit, to name a few) are marketed as educational games that can teach the basics of coding in a form accessible to younger audiences. And the way these games go about teaching coding is... by having children arrange visual elements on grid-like maps or in sequential slots in order to accomplish a certain goal. While that goal is typically internal to the game (guide the protagonist to the end of the level, move crates in a certain way) and thus very different from the extrinsic goal of the likes of Construct 2 (create a standalone game), the process itself is strikingly similar. Game makers are, if anything, more complex as they offer a much wider set of “building blocks” that can be put to many more uses, although puzzles in Lightbot-like games can be perhaps as challenging as putting together one's own game in Construct 2: puzzles are, after all, designed to be difficult, even if the means needed to solve them are fairly easy to master. Essentially, though, the process is identical: whether you are solving a puzzle or making a game, you do this by manipulating visual elements into a sequence.
Figure 2. A level in Lightbot
So on the one hand we have a subset of software surrounded by a rhetorical convention that describes its mechanics as a more accessible alternative to programming, and on the other there exists a subgenre of puzzle games where the same mechanics is conceptualized as a basic form of coding, an entryway to the more sophisticated kinds of programming.
And neither rhetoric is particularly wrong. The former is based on narrowing down the notion of programming to its archetypal form involving complied or interpreted textual code; the latter, on the contrary, expands the notion beyond this archetype, supporting a wider understanding of programming as “any activity where a computation is described according to formal rules” . In this wider sense, it becomes impossible to argue that game makers require no programming at all. Rather, they rely on visual programming, as opposed to the more conventional text-language programming. “Visual programming” is in fact an long-established term , and the paradigm it denotes has been used in various spheres beyond games, from robotics (Microsoft Visual Programming Language, ICon-L, ROBO Pro) to data mining (Orange, KNIME).
To be fair, some game makers avoid the misleading claim of involving no programming at all by wording their pitches more carefully and merely pointing out that “no programming skills” are required. (Even so, they hardly ever explicitly state that programming as such will be involved[iii].
Some applications, such as Tynker and Hopscotch, fall in-between the two kinds of software, being marketed as games whose purpose is to teach programming by enabling the “player” to make their own games. Rhetorically, they are closer to Lightbot than to Construct 2 as they do not shy away from admitting some programming is involved. Yet in terms of how they work and what they actually do they very much resemble “game makers.”
Here is one particularly striking example. MIT’s Scratch is a well-known visual programming language designed to help young learners design their own games and applications. Scratch’s official page describes it as a tool that lets you “program your own interactive stories, games, and animations,” explaining that “ability to code computer programs is an important part of literacy in today’s society.” Scratch’s innovative and intuitive interface inspired a number of similar tools. Of these, Stencyl is perhaps the best known, reproducing the look and feel of its predecessor to such a degree that its creators felt compelled to ask Mitchel Resnick, Scratch’s creator, for permission to “adopt the Scratch approach.” Unlike Scratch, Stencyl is specifically intended for videogame development and is more powerful in terms of functionality. And yet, despite having more advanced capabilities (and, accordingly, a more complex visual “vocabulary”), Stencyl is marketed under the slogan “Create amazing games without code.” Thus, despite looking similar and working in essentially the same way, when it comes to programming, the two tools adopt different rhetorics.
It has been long since pointed out that no single, all-encompassing definition of programming exists, or indeed can exist . Even such a technical activity is bound to be entangled in conceptual debates. This is even more obvious now when programming is almost half a century older and considerably more diverse.
Throughout its history, programming has become increasingly accessible to the general public. Part of it has to do with the advances in hardware technology, with computers becoming increasingly accessible both in terms of the price and ease of use, and with the development of informatics education. But various developments in the history of programming itself have also contributed: the invention of high-level programming languages, their increasingly human-readable syntax, the specialization of programming languages and tools, the emergence of libraries and frameworks, the rise and decline of the rapid application development tools such as C++ Builder, and so on. And, as the C++ Builder example illustrates, this has not been a linear process, but rather a complex and multi-layered one.
Yet in its totality this increasing accessibility of programming is just one facet of an ever-growing “digital DIY”  culture, which in turn is part of a larger process: the increasing accessibility of media production tools. Think about movies shot on an iPhone and 3-D printing stores on street corners. Anderson has described it as "the new industrial revolution"  though perhaps it equally makes sense to see it as a cumulative, evolutionary process.
As this process continues, we have every right to expect that more and more hobbyists will be empowered to make their own digital games. But will it be thanks to the fact they will no longer need to know how to program, or will it be that becoming a programmer will become easier than it has ever been? There is really not much of a difference.
 Yasmin B. Kafai and Quinn Burke. 2013. The social turn in K-12 programming: moving from computational thinking to computational participation. In Proceedings of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, 603-608. DOI:http://dx.doi.org/10.1145/2445196.2445373
 Lev Manovich. 2013. Software takes command. Bloomsbury, New York, NY.
 Mordechai M. Ben-Ari. 2011. Non-myths about programming. Commun. ACM 54, 7 (July 2011), 35-37. DOI:http://dx.doi.org/10.1145/1965724.1965738
 Nan C. Shu. 1988. Visual programming. Van Nostrand Reinhold, New York, NY.
 M.V. Jones. 1969. Computerizing a Government Data System: A Management Overview of the Steps Required and the Time Needed. The MITRE Corporation, Bedford, MA.
 Paul McFedries. 2007. The hobbyist Renaissance. IEEE Spectrum, 44(6).
 Chris Anderson. 2012. Makers: The New Industrial Revolution. Crown Business, New York, NY.
 James Paul Gee. 2003. What video games have to teach us about learning and literacy. Comput. Entertain. 1, 1 (October 2003), 20-20. DOI:http://dx.doi.org/10.1145/950566.950595
[i] I capitalize to distinguish the “original” Literacy (reading and writing ability) from the more recent understanding of the term as any set of competencies, as adopted, for example, by Gee .
[ii] That would not, of course, be what Lev Manovich meant: many kinds of cultural software require extensive technical skills; after all, compilers and interpreters are cultural software too. Rather, I am specifically referring here to the “game maker” rhetoric described in the passage.
[iii] Tools that, in addition to visual programming, support actual scripting (such as GameMaker with its GML language) do, however, point out that optional programming capabilities are available in order to appeal to the more tech-savvy consumer.