What counts as "code" or "programming"? This was an interesting topic between @stevekrouse and @pbiggar in podcast #43 (Unveiling Dark). Some of the contested areas were: * Incidental (accidental) complexity, vs essential "this is what it does" code * Whether it looks like "code" / is symbolic * Whether it's the boring / tedius stuff, or the "fun" part of programming What does everyone else think?

Controversial (though maybe not in here): excel and scratch are both programming

I'd say if you're composing a computation (aka a transformation of data) which will be carried out by a machine, you're programming

One view was that even just specification of things counts as "programming", especially if you would normally "write code" to do so. Bret Victor presents the opposite view in "Learnable Programming": Dragging shapes onto a canvas "isn't programming", but neither is writing code to do so - it's just a very cumbersome form of illustration (i.e. of specifying). Thus, learning how to draw shapes with code is just learning how to use a poor interface (code) for doing something that's "not programming"

My view of code is probably rare. I would consider DNA code. I would call it a 3-D spatial notation. I would as well consider chemical molecules as a type of 3D spatial notation. I would say human invented notations/languages are a subset of code. Programming I would generally refer to as what we typically think of: writing in a programming language. I would consider psuedocode a programming language. I would agree that excel and scratch are programming. I would call a "

Are there things anyone would consider to be programming, but not code? Or code, but not programming?

Transcript: https://futureofcoding.org/episodes/043 Pretty sure I've read it before, but seems worth a re-read.

We interact with computers using artificial, formal "languages". These aren't human languages, they are designed primarily to be understandable by the computer, with usability for humans taking second place. But they do have syntax and grammar. An utterance in one of these languages is "code". When you type a command in the Bourne shell, that is code: you are writing a short program and executing it. A URL is also code. But code doesn't have to be textual, any more than human language has to be textual (eg, there is also speech, and sign language). "Gestural" interactions with the computer (eg, in a GUI) are another kind of formal language, and they are also code.

I'm struggling to see what ground this thread is covering that we haven't already discussed in the past week or month. OP is fun to read. The rest of you are arguing angels and pinheads.

I don't see myself arguing angels and pinheads. I'm arguing for a definition of "code" that I think is necessary in order to make fundamental progress on the FoC.

1. It's an interesting topic with very different opinions (at least some of the specifics), which are also interesting. 2. More practically, breaking down base assumptions and getting to know the different points of view (rather than assuming what they are), especially about something so fundamental, adds a lot of context for what it is that we are wanting to shape. Is it the future of symbolic expression, or of user interaction, or what?

I don't think we can build an engineering discipline or a scientific research program around the future of coding, if the definition of code and coding are a mere matter of opinion. I think we need a principled definition based on objective criteria, otherwise we don't have a field of study.

Assumptions you're making: * FoC needs to be a new discipline. * FoC requires a "research program". * A research program must define its terms before it begins. I thought OP was pretty transparent about struggling with definitions. It doesn't prevent trying out a new approach. The rest of us too are building projects without having a definition. That seems like a pretty good sign that the definition is not on the critical path. The day I see a useful definition I'll start using it with relief. In the meantime it's just one of the many ambiguities I have to wrestle with. Like peace or hunger, it seems unlikely to resolve by discussion alone.

The main intention is to spark thought and discussion, especially on something open ended that not everyone agrees on. I don't think this community (here on Slack) can or should be a formal anything - we range from hobbyists to serious researchers, etc. But regardless of where anyone is on that spectrum, "Perspective is worth 80 IQ points" (AK)

Very interesting subject that I wanted to investigate and to see what people here think about it. So, thanks @Dan Cook for asking and all for sharing your thoughts!

That's also my thought: programming is specifying behaviors, specifically when the behavior is something "set up" to happen versus just doing the behavior yourself on the fly. This does not necessarily involve code, and not all coding is programming. But when the code specifies (or contributes to) behaviors, then it also counts as "programming", because the code is the vehicle for "setting up" the behaviors.

Yes, and I guess for me, this "set up" can also happen live, i.e. I see the behavior at the moment I set it up in my tool. Like when I change a bit of code in Scratch and see the cat behavior changing.

Hmm, well how about this: I'd say that giving a list of instructions to an RC car (e.g. move, turn left, move, honk) is "programming", because the instructions were set up / batched, even if those instructions are not persisted afterward. But I would not have called it programming if the RC car just responded in real time to immediate button pressing on the controller. ... But maybe I can reconsider. Maybe it's about specifying behavior through some interface or language, regardless? But then would you say you're programming a drone every time you fly it around? Maybe it is, even if one wouldn't normally think about it that way?

For me, in your RC car example, you give instructions using a code it can understand. Even if you don't write it down. It is the same difference between a bash script and you executing each line of the script in the terminal. And, for me, you are programming it. You are specifying its behavior, but you do it live.

I actually have to totally agree with your previous reply. Recording and echoing back to make it "feel" more like "programming" seems to superficial of a difference to determine whether it qualifies. More thoughts in a bit...

Well, Dan, I fully agree with you when you said "...and not all coding is programming. But when the code specifies (or contributes to) behaviors, then it also counts as programming". I guess this spots a difference in concept between the two.

"contributes to" is touchy. Does specifying a (static) shape or style affect behavior? Can any declarative thing also be interpreted as a command to "make it so"?

And for me, "programming" is some kind of mind set, i.e. "I want this thing to behave like that, what do I need to do for that?", and coding is part of this, but as a technical and concrete activity/tool.

Yeah, I'd say that's roughly the essence of it.

If I separate the two this way, it is because building environnements for FoC/FoP (or FoPaC ;-)), is creating tools that help people doing programming activies by helping them effitiently produce code. Then focus on "programming activities" from the "UX" point of view, and focus on "code" as the raw material those tools are manipulating.

I retract my previous statement, and hold that sending a sequence of commands to be executed by an RC car is programing, but controlling it in real time (i.e. do what I say as I say it) is not programming. I originally conceded that the difference was too superficial to say they are different. But I think it was actually just a superficial example of programming. It's not necessarily about whether commands are "prepared" or "batched" (although that is what qualifies as "code"). It's about specifying or altering the the behavior of/for something else, rather than being in direct control as it happens. Otherwise you are the one doing the behavior (albeit through some interface). It just so happens that the most familiar form of programming (when thought of as such), is to "script" the behavior ahead of time, in which case that script is called "code". But a person (or machine learning AI) can be programmed to behave a certain way through conditioning or +/- reinforcement -- no "code" involved (for the programmer) Although if you go see a play or a musical, people follow a "script", and you are given a printout of "the program" (here's what will happen, here's who is involved, etc.)

It's about specifying or altering the way something does (or will) behave, rather than you being in direct control as it happens. Otherwise you are the one doing the behavior (albeit though some interface).

Well, I find your distinction between the two very interseting and usefull. So there is two kinds of activity: programming and controlling (or "commanding"?). Another example might be MIDI in music. You can control a midi instrument with midi controllers (keyboards, control surface with faders...) or you can program it with sequences via pianorolls or with generative algorithms. And to blur a bit mors the frontier, your midi instrument can be a program (say coded with MaxMSP our PureData).

Very interesting! That reminds me of a "programmable" game controller, which could record a sequence of button-presses (with timings) and associate it a button. So I could record a couple combo moves in Street Fighter II, and then just push the right button to replay it at any time. Is call that "programming" the buttons. I think that's essentially the same concept of "programming" as for MIDI, mixers, synthesizers, etc.

Audio programming (eg, for MIDI) is real time programming, though.

I'm not actually familiar with how audio/MIDI programming actually works. Is it "real time" in the sense that you program it as it is running or being used? Or in the sense that you are capturing or manipulating sound in real time? Or is the programming is done ahead of time (e.g. program it, then run it), but relates to real-world timing which will be relevant when it is run?

Well... Hmmm... All of that! 😉 You choose. But I guess Doug wanted to focus in the fact that the raw material you handle with Audio (and MIDI) is stuff that happens at given times in the real world. Hence "Real Time" programming.

> Is it "real time" in the sense that you program it as it is running or being used? I would call this "live programming". Live programming can also be real time programming, especially since it is popular for musical performances.

Thanks, that's the term I was looking for: "Live Programming" I guess it's unreasonable not to expect people to interpret "X programming" to mean "programming for X", and thus we need separate terminology for when programming is X (e.g. "live" and "visual" programming as opposed to "real-time" and "graphical" programming)

My definition of "code" is based on expressive power, and on what abstraction mechanisms are available. It's not directly based on how code is displayed to the user. I don't consider SVG to be code, because there is no support for parameters, conditionals or iteration. Postscript, also a vector graphics standard, is code. Inkscape, a graphical/GUI based editor for SVG images, has groups and layers, which are abstraction mechanisms, but that's not powerful enough to quality as code. Some parametric CAD programs are powerful enough to qualify as code, even though what's displayed on the screen is the geometric model, which you can modify using direct manipulation. When you edit a pixel based image using a simple image editor like MSPaint, what you see (the pixels) are all there is. When you transition to a vector-based image editor like InkScape, now the pixels that represent your image are no longer all that there is. The image is partitioned into geometric objects, and each geometric object has hidden state that represents its abstract structure. This state can be revealed and edited. a bezier curve has control points that you can edit: they are normally invisible, but you can make them visible on command so that they become editable. When you transition from Inkscape to a vector based image representation that is powerful enough to be considered code, now you have more hidden structure that needs to be revealed on command so that it can be edited. If you are deeply embedded in text-based programming culture, then you might think the only way to do it is to have two panes: one shows a traditional text based program, and the other show the image that the program constructs. However, that's not the only possible user interface. Constraint based CAD programs have been demonstrating a different way to do it, going back to Ivan Sutherland's Sketchpad UI in 1960.

I think you're saying that something counts as "code", to the extent that using it counts as "programming". On the one hand, it's somewhat of a closed view: code is just the means for programming, and programming is only understood in terms of code. On the other hand, that's probably the most meaningful and practical definition for 99.99% of anyone who's even talking about "code" to begin with. So I guess it depends on whether your context is immediately practical, or about reinventing everything from first principles.

As I mentioned before, the definition of "code" keeps changing. In 1956, "code" was machine code, and Fortran programs were not code, they were a way of programming without writing code. Today, the Scratch programming language is considered "no code", despite it being a very thin layer of graphical syntax on top of a conventional imperative programming language. For programming language research, I need a definition of "code" that is general and timeless.