[harry8]

The essence of programming is designing a way to transform data. You ask yourself, "what is the nature input data and how it arrives" "what is the nature of the desired output data."

When I started learning programming from books, the internet and later formal study this wasn't stressed nearly enough. A program transforms data. So much else starts falling into place about all the various abstraction techniques useful to perform that kind of transformation (procedural, oo, functional etc) and technologies used to assist, (testing, debuggers, etc) once you keep that thought front and central in your mind. At least I feel it really did it for me.

Reading code is the same. Where are the places the data coming in? Where is it going out? Sometimes this is a better place to start than "main"

I'm sure that's really obvious to many but I'm not sure it is to the author in a way that is being successfully communicated:

”programming is a tool to solve problems that you have in the domain of computers”

Taking a baseball bat to a computer, on some level can meet the suggested definition of programming, but I don't like it that it does. I also don't much care for the use of "problems" there either.

The above is especially opinionated because I'm particularly interested if people disagree!

edit: I'm definitely still learning programming here.

[gingerBill]

Author of the article here:

I completely agree that the essence of a "program" is transforming data. In my previous article which I linked to in the main article, I specifically state "The purpose of a program is, and ought to be, something that transforms data into other forms of data".

But the essence of "programming" is different, and I stand by statement that "Programming is a tool to solve problems that you have in the domain of computers". And this article was an extension of the previous article meaning that taking it out of context has caused this confusion. But the term "programming" embeds the concept of "a program" already: programming produces a program. Programming does not start with hitting the computer with a baseball bat.

[BerislavLopac]

I've argued for a long time that everything in programming comes down to:

1. Data. It can be in many different forms and structures, more or less strictly typed, and a big part of writing a program is determining what it looks like, and what it should look like.

2. Procedures to work on that data. They can transform the data, remove it, reshape it, convert it, or do any number of other operations on it, simple or complex.

That's all there is to programming.

[phforms]

Maybe we should differentiate the essence of programming from the essence of software development:

Software development, in my understanding, is about designing and implementing tools to solve particular (classes of) problems. Exactly what is being described in the article.

I think Programming in general is about writing instructions that (maybe not only) a computer can execute to produce (the desired) effects. These instructions may or may not involve input data and may produce side-effects along the way and may not even produce output data (although one could say that “nothing” itself is data similar to how we use 0 as a number).

I don’t think that we need a purpose for writing programs. We can program just about any nonsense and we don’t even have to ever execute it. I think “problem solving” is already too specific.

Even though it makes a lot of sense to think about programs as mathematical functions that transform data, underneath our abstractions are building instructions for the computer to execute and they tend to produce the desired output if we are doing it right and there are no interfering environmental circumstances.

A simple substitution of input data with output data would be the most primitive example, although it would be trivial. To produce non-trivial outputs, we need to replace the substitution with a (more complex) algorithm. Algorithms are tools that solve particular (classes of) problems. So here we are, doing software development, because we actually need a tool.

[hyperpallium2]

Pedantry: the only exception I could think of is a timer (delay, alarm clock), where the output is when, not what. sleep 10

Yes, information technology is for processing information.

Any transformation can be decomposed into lossy and lossless components (aka bijectve and non-bijective; reversible and non-reversible). The nice thing is that the lossless component can be automatically checked for that property.

[SPBS]

Reminds me of this comment from antirez back in 2012: https://news.ycombinator.com/item?id=4560591

> This is one of the few programming quotes that is not just abstract crap, but one thing you can use to improve your programming skills 10x IMHO.

> Something like 10 years ago I was lucky enough that a guy told me and explained me this stuff, that I was starting to understand myself btw, and programming suddenly changed for me. If you get the data structures right, the first effect is that the code becomes much simpler to write. It's not hard that you drop 50% of the whole code needed just because you created better data structures (here better means: more suitable to describe and operate on the problem). Or something that looked super-hard to do suddenly starts to be trivial because the representation is the right one.

[aargh_aargh]

True and useful way to think. Such a matter of course to me that I would also forget to mention it.

Output can also be an action performed through an actuator (robotic arm, welder, coffee pot, ...). Could be considered as data (signal coming to the actuator) but the "problem solved" is the action itself (and usually involves a feedback loop).

[kaba0]

> The essence of programming is designing a way to transform data

I don’t agree here - in my experience data-oriented programming is only a subset of all useful programs.

For example, a game is in my opinion not like that. Sure, very pedantically it may be considered a “mathematical function”, but then so is every human interaction, and that’s not a useful pedantism.

[grumpyprole]

Why is a game not like that? It transforms a stream of input events into stream of output events (video and sound hardware commands). Yes there is lots of state, but that can also be thought about as data that is transformed, step-by-step.

[Sakos]

I'm confused. What do you think games do with those tens of gigabytes of data?

[bmitc]

I would agree to some extent, but I would add to this particular sentiment that it's also about the representation of data.