What Is the Essence of Computing? (2017)
erasmatazz.comI just came across an apparently famous one-liner for the first time, which can be paraphrased in this context as:
"The essence of computing is the separation of Church and state"
Which is a pun on Alonzo Church's lambda calculus (stateless) and the notion of stored state (in memory), which I suppose can be aligned with processes and objects, respectively.
source:
https://ebrary.net/65011/computer_science/separation_applica...
So I had originally wanted to mock this article for a number of reasons: the fact that it doesn’t directly answer its own headline question, the fact that it spends way more time talking about physics, the fact that it doesn’t connect “first principles thinking” with “the essence of the problem”, the fact that the title is phrased like a Zoolander joke..
> Is reality a collection of objects or a system of processes
But when I read this phrase, something struck with me. I kind of hate that we’re originally taught OBJECT oriented programming, specifically that the name is “object-oriented”. I know that the ‘object’ in OOP and object as he is using the phrase above are not necessarily the same technical definition, nonetheless it took me far too long to understand that software engineering is not about the objects: its about the systems. OOP feels like a an awful misdirect as to where one should direct their time and attention in writing code. “You told me my code should be object oriented so I thought real hard about making sure I used objects!”
I would far rather have a junior write one flawless function that DoesTheThing™ rather than a fleet of mis-organized objects that scatter the idea incorrectly. Why? Because DoesTheThingScript() can be more readily and easily refactored than ObjectOrientedMess™.
Gilbert Simondon talks about change & individuation, with a term "allagmatic" or latter I think Yuk Hui re-dedubbed cosmotechnics. The are some lovely reflections on a similar duality, between systems and objects: Simondon reflects that reality is comprised of, depending on point of view, either structures (objects) undergoing operations to become new structures (s-o-s) or operations yielding new structures which in turn shift the system into new operations (o-s-o).
In terms of code organization, i do think there's certainly a clarity to DoesTheThing. But as we evolve & change & begin to do different things, or as we have different ideas, there's more allure to shifting power from the script into the entities being scripted, to encompassing more capability & responsibility in the objects. Alas we often bungle up & confuse our object systems quickly- when we make bad picks in a bigger system, they stay with us, where as DoesTheThing will more than likely be replaced or become a cog in some other bigger script; it's faults & limitations stand less chance of becoming visible.
> allagmatic
> cosmotechnics
Thanks for new favorite words.
DoesTheThing is fine for a function. E.g. if TheThing is cosine(x) then that works. But most computer systems are not functions. They have some internal state. So it becomes DoesAThing. AThing may different every time depending on the internal state. This is neither an object nor a process in the articles terms. It's more like an object in OOP terms.
Perhaps what I mean to convey here is that OOP (to my dumb newbie brain from N years ago) sounded like classes/objects were the hammer, everything else was a nail. The truth as I see it now is, I think, more that the patterns/problem statement are the hammer, and classes/objects are the nail. I spent a long time early on trying to map real-world objects to coded abstractions. In practice, at least as far as enterprise goes, it’s nothing of the sort: the objects we tend to create are DoThingClient, BrokerThingRepository, CreateThingFactory, HandleThingSevice, and then whatever STL & Framework you might build/ship with. Everything else might be a “class” out of restriction by the language, but they’re really just data records or procedures.
I’m sure things might be different in game development, embedded, OS, etc. But object oriented programming feels like it doesn’t quite convey what we actually do as we trying to get a senior-level understanding of SE.
Anyway, this is my hottake and it’s totally warped around my perspective
> the patterns/problem statement are the hammer, and classes/objects are the nail.
Very good analogy. Matches my experience also.
With object orientation you can not even fry an egg because you can not prperly decide whether frying is a method of the egg, the pan or even the stove.
Ist's a procedure which takes a piece of food, a pan and an oven and produces a fried egg.
>Alan Kay has famously described Lisp as the “Maxwell’s equations of software”. He describes the revelation he experienced when, as a graduate student, he was studying the LISP 1.5 Programmer’s Manual and realized that “the half page of code on the bottom of page 13… was Lisp in itself. These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over.”
https://michaelnielsen.org/ddi/lisp-as-the-maxwells-equation...
A much more concise Maxwell’s Equation of Software is the Binary Lambda Calculus self-interpreter
as detailed in https://tromp.github.io/cl/Binary_lambda_calculus.html#Lambd...(λ11)(λλλ1(λλλλ3(λ5(3(λ2(3(λλ3(λ1 2 3)))(4(λ4(λ3 1(2 1))))))(1(2(λ1 2))(λ4(λ4(λ2(1 4)))5))))(3 3)2)(λ1((λ1 1)(λ1 1)))In words; state in flux
It's really hard for me not to respond with pure snark. But I'm going to do my best.
Since the essence of computing is processes, viewing all programs as processes, it should be really easy to tell if any given process halts. But, it's not.
Math has been around for a long long time, but it turns out there are some really hard problems that took thousands of years to even discover. It took a long time to decide that no internally consistent system can prove that it's internally consistent.
Software, is pretty new. And software got kicked in the teeth right at its inception _because_ process and data are highly context sensitive.
Now, I'd agree, that folks could probably put more thought into organization of data, and deeper thought about what process should operate on that data. But it's not like waving your hand and saying computers are about processing is particularly helpful. I don't need a machine to translate a program into its result. It might take more than my lifetime, but I can work it out with a pencil and paper.
The hard part is building a process that's worth a damn. The thing flips back and forth from being an object, a row of bytes in memory somewhere, to a set of changes over time in a processor. (this could just as easily be brass gears, or punchcards in a loom).
You can choose to look at it however you wish, but it's both. It's really hard to get right.
> it should be really easy to tell if any given process halts. But, it's not.
In theory, some processes could run forever. In practice, they do not. For example,
usually works for me. If it doesn't then a hard powerdown usually does the trick.sudo shutdown -h nowWhat's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame or number of cycles. For practical time frames an empirical approach seems easy (just wait and check it), but I have no reason to believe that an analytic approach or proof would be "really easy" even if it was just N steps of symbolic execution.
> sudo shutdown -h now
That, is funny.
There are a bunch of approaches, one approach uses 'gas' so you have to pay for computation steps. A bunch of SAT solvers use a clock - if you don't finish in 5 minutes, you get the axe.
And yes, for the vast majority - it's fine. shutdown -h works great. Not many bugs are from "the set of all sets that do not contain themselves" paradoxes.
> What's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame.
Everybody sort of learns about thundering herd in their own way. And retry loops. And many more.
We try stuff, learn how it fails and fix it. And, as far as I know, that's the best we can do. Thinking about programs as processes (I think the author means natural process not unix process) is helpful, but it's not a magic wand.
A process is an abstraction. It is not the essence of computing.
> Thus, the heart of any computer is a processing machine. That is the very essence of computing: processing.
Doesn't that just beg the question though?
What is the Essence of Processing?
Good point. The essence of processing is the transformation and combination of signs. Processing a sign is a kind of energy transformation. The process takes input signs, performs some kind of energy transformation, and produces a new sign, with different signification, which may be a better or more useful signifier for some purpose. Think NAND gates, or neurons. Example: if it looks like a duck and quacks like. duck, then it's probably a duck. A neuron summing 'looks like a duck' signal and 'quacks like a duck' signals is a more reliable signifier for ducks than either of the inputs. As for signs, see C S Peirce or Ruth Millikan for a clearer explanation. TLDR: Signs are relations between objects and processes (Sign, Signifier and Interpretant)
That's still begging the question - what is a sign (symbol/signifer)?
I'd suggest it's a signifier for a subjective state. You can persuade a symbol processor to do anything to any symbol collection, but the results are only useful if the symbols mean something - which is to say they have some analog to subjective experience.
If that's the case then computers and symbol processing are tools for working with subjective experience.
This does not mean there's a possible mapping between all symbol states and all of subjective experience. It's often assumed this is true, but it's a conjecture and has never been proven. It won't be proven until we know exactly what subjective experience is.
So the best we can say is that computers are tools for working with a subset of subjective experience.
Which is interesting enough in itself without being absolutist about it.
> What is the essence is computing?
According to Ken Thompson and Dennis Ritchie the essence of [communal] computing are fellowship and close communication.
not sure if it's a function of this site's older design, but I found myself reading this at a much slower scan rate than I do most websites.