This is a somewhat myopic and outdated description of what "code" or "software" is. I'm writing an article on this, but software is a much broader idea and domain than just getting computers to do something. At a minimum, it includes getting a computer to do something, communicating between humans and not humans and computers, and encoding a domain. All this adds up to software being "executable knowledge", which makes it far more powerful than thinking of it as just bits executing on a machine. Thinking of it this way also highlights all the problems with software, because the process of system design and encoding knowledge is downright hard and not something humans excel at. Getting a computer to do something is rarely the hard part aside from specific instances where pure performance is necessary.
It isn't surprising to me that the best software developers I have met have been those who either had no computer science degree or got it after having some degree or major interest in another field, typically a liberal arts or science field. Liberal arts are actually the study of systems in disguise because of the need to connect together various ideas, events, etc. that do not necessarily have clear delineations or relationships.
Are you equating "computer science" with "coding"? Because it's really not. CS studies systems, complexity, requirements, domain knowledge, etc.
I'm not arguing against people from other fields bringing valuable insight; I'm disputing that CS doesn't also involve the study of complex heterogeneous systems or that it is about "coding".
Seems like you're describing a bootcamp or coding school instead.
Systems Analysis and Knowledge Engineering typically assume corporate/industrial philosophies and goals.
Broader human considerations - political, social, cultural - are very peripheral in CS. They get some token attention but they're always subservient to business values.
The idea that software is primarily about human relations of all kinds is novel and rather subversive.
> "They get some token attention but they're always subservient to business values"
Hard disagree. CS education doesn't have business at its core, but science. It's all about systems design, theory, formal verification, requirements gathering, math, logic, etc. It's neither about (primarily) business nor coding concerns. You probably don't need CS for those.
Isn't the core problem that universities have started offering far too much under the "Computer Science" umbrella. If they where to split it up into 5 or 6 different degrees, like Computer Science, Computer Engineering, Software Engineering, Human Computer Interaction, Business Systems design etc. then many of these problems of definition and meaning would disappear.
Computer science is not a science. Computer science typically bounces between mathematics and engineering, with some unique aspects of its own. But it definitely isn't a science, which typically needs a loop of hypothesis, observations, and theory.
That's a narrower argument that the one I wanted to make, which was that CS is not programming; it's theory/research/practice more like the traditional sciences.
Whether it's a science or not is not as clear-cut as you claim [1]. There is argument about this, like about many things claiming to be "science". Here's a relevant quote from Wikipedia, attributed to Newell and Simon:
> "Computer science is an empirical discipline. We would have called it an experimental science, but like astronomy, economics, and geology, some of its unique forms of observation and experience do not fit a narrow stereotype of the experimental method. Nonetheless, they are experiments. Each new machine that is built is an experiment. Actually constructing the machine poses a question to nature; and we listen for the answer by observing the machine in operation and analyzing it by all analytical and measurement means available."
This does seem to leave out the more "mathy" part of CS, which isn't about building machines at all. For the record, I think CS is science.
In the computer science world yes. But the word also exists outside of that context (and did so long before computers).
Data is the plural of datum. A datum is a piece of information. Of course not any piece information is automatically a datum, as that noun implies a certain structured nature or a normative perspective on that piece of information.
Certain information only became commonplace because it became a datum first. Before using family names as an identifier many people had no family names, they were identified by their first name and by the places they grew up in.
Data is information about things and code is information about how to transform data. Every program transforms input data to output data. Code is interpreted by the computer. Data and code are encoded to bits for the digital computer.
My answer tried to be as generic as possible and leave out the "real world" and implementation details in general. There are fundamental limitations to what you can express in four sentences...
Compilation is "just" an intermediate step between code and using it in an interpreter. The interpreter can be pure hardware, mix of hardware and software, or you can do it on paper yourself (given time). These are implementation "details". Also, to me code is not a synomym with software, since I'm not referring to programmability, only to the transformation aspect. Programmability is an implementation detail. You may perform a transformation with hardware only, as mentioned above. The hardware itself could be described with code, e.g. in Verilog language. Manufacturing a silicon chip based on Verilog code is also an implementation detail.
In fact your CPU/PC is hardware and it is making transformation from input data to output data. In this case, besides the other input data, like keyboard input and files on disk, you may consider the binary code as part of the input data. This is where the confusion starts to happen. This is an implementation detail and should not be confused with the general notion of utility we want to have. Code is "only" the means to an end. We want to do stuff with the machine. We want to transform input data to output data, since that is essentially what we are after. For the goal of getting stuff done, data and code are separate things.
When saying "data is interpreted by code", it is partially correct. First of all data carries meaning, as in meaning for people (the data user). Data is encoded to some format (which is also data, but implementation data) and you could say that this encoding is "interpreted". However, the encoding is "just" an implementation detail which depends on the machine you are trying to use for the transformation. When the computer paints pixels on your monitor, it transfers data bits through display driver, through HDMI protocol (for example), to monitor itself. There are plenty of "interpreters" on that path. On the screen the pixels could represent the letter "A" and that could carry meaning for you (depending on the other stuff on the screen). This is why I stated that data is information about things. Encoded data is an implementation detail and varies between implementations, but the "true" data is essential and implementation independent. It carries meaning and utility value. Essential data is not interpreted by code. The user (a person) interpretes the essential data.
Code is data for the compiler. The compiler transforms source code (input data) to object code (output data). Code is data also for the interpreter. Algorithm contains all the essential information about the data transformations to be performed, and code in form of programming language text, is an implementation of that algorithm in the specific programming language. Algorithm is programming language independent. It's fair to say that by code I mean the algorithm. But also an algorithm must be presented in some form or another, so its code. :)
I would say that data defines as something that might convey information, might in the sense that there are one or more interpretations of it that are meaningful to something. This sentence has plenty of open ended terms, however.
Code is data that can be executed, provided that there is a something that offers an interpretation of it. It think we must claim that this interpretation is meaningful to something.
Executability is a semantic in the context of interpretation, which ties it all back into what data is again. Something something Apply/Eval.
Data are instructions for the computer interpreted in the context of a program. Or no program in the case of instructions which can be interpreted directly by the computer.
That is, data are programs, programs are data. Just need to establish the environment in which to execute/process them.
Right, except what got me thinking is that "programs" can be conceptually seen as a sequence of "instructions" to the computer. Whereas it is more difficult to think of data as "instructions". Data is more like a model of the world, than a set of "instructions".
It is, but it also influences how the software and hardware actually execute, making it a kind of program. Essentially every program that accepts any kind of data is really operating as a virtual machine, a software specified computer. It interprets the data and performs actions conditioned on that input.
mp3 files are instructions to an audio producing "computer", mp4 to an audio/video "computer". Whether it's a software description of the machine or a hardware implementation. Zip files are data, but when run through a decompression program they determine what gets decompressed (the program determines how) making them instructions for the decompression computer. The text of a text file opened in an editor providing rendering instructions. TCP packets are data, but they influence the TCP state machine, which is an explicit rendering of the idea that the software (sometimes hardware in this case) is describing a computer and the data (packets) represent instructions that effect the state of that computer.
However, this interpretation is usually not explicit so the manner of these virtual machines is ad hoc and ill-specified (if at all).
and there you have an unanswerable question! :-)
at an atomic level in computing, as others have said, it's a stream of ones and zeroes..
after that everything else is implementation, i.e how to interpret, use, store etc.
In fact it's one of the "bug bears" in computing that there are so many "data format standards" (used loosely not definitionally)..
or the age old joke:
"The good thing about (data) standards is there are so many of them!"
Well said. Code stays as it is, typically. Data changes.
Of course code can modify its own 'code". But that makes it much more difficult to reason about its behavior. It is good to have some "invariants". If we can assume that code does not change except when the human author changes it, then it becomes much easier to reason about the changes the program may cause to the data.
> This is real. A Scrum Master in ninja socks has come into your office and said, “We’ve got to budget for apps.” Should it all go pear-shaped, his career will be just fine.
It's funny how organizations manage not to fall apart with so many people with so different motivations. For example, an SWE can despair in 2022 because they work on Openstack bugfixing or on mainframe JCL2 batch jobs, but here this exec worries about his position being undermined by some software project.
Oh I see. Yeah when you do a ctrl+f it doesn't say something like "let us take a picture of you" but I do see the cert at the bottom/placeholder when you decline.
Suppose it could be a wow factor/adds to the interactive elements of the page.
Yeah it wasn't as immediately obvious to me what was going on as I think the author expected, seeing something ask for my camera unexpectedly is alarming! But the article was otherwise pretty great.
First, bear in mind this isn't written for a technical audience. Nevertheless, it's worth the time if you finish it.
Case in point: when this was first published, I was just starting out my career writing software, and knew very little about the industry I was entering. 7ish years later, I still think about it often.
The argument that we likely live in a simulation is similar to the the cosmological argument that allegedly proves the existence of god; and it rests on the same unsound assumption, namely that the existence of entities in reality follows from the rational arguments that your mind can imagine about those entities.
Sound approaches to knowledge must operate in the opposite direction, drawing insights from observation of phenomena existing in the world.
Assuming that the world is as we deduce it to be, without then proceeding to check that the world behaves in accordance with our deduction, is a failure that delayed the advance of knowledge until the use of the scientific method became widespread.
I was also looking for one (well, two) yesterday... even sent bloomberg a mail to ask if backorder was still possible (they said no and to check amazon/ebay/etc).
