I do think the whole "code is data" thing is a bit overstated. The earliest computers used paper tape for data records:
At Bletchley Park, the "data" (ciphertext to be broken) was encoded onto the paper tape in the photo. The "code" was hardwired into the design of the machine & its electronics, and was most definitely separate from the "data" on the paper tape. Later, the first "stored-program" computers used electronic memory to hold both "code" bits and "data" bits. So one could change both the code and the data more easily. However, they are both just bits stored in a single memory system. A simple program accepts bytes as input and produces bytes as output, then terminates. Only humans can interpret some bytes as "code" and other bytes as "data", based on intended future usage. To the computer it has always been a case of "bytes is bytes". So, what is the difference between data & code? Code is what is executing on the CPU; everything else is just data [1]. Some data is never executed. Because it has no "motion" it is simpler than "code" which is in some sense alive and in motion and has more ways to cause problems. So, the basic idea is that "data" is simpler than "code" because "stationary" objects are simpler (& more predictable) than "moving" objects. Since we like "simple", there is a preference for data over code for many uses. However, there are limits. Consider adding two numbers. I could give you a lookup table for all possible pairs of 32-bit integers. I hesitate to estimate the weight of that much paper! So, the lookup table is a very costly solution, but one that is "pure data". Or, I could give you a simple recipe for calculating the result, which would fit on one piece of paper. This set of instructions is "code", and is not as simple as a the lookup table. It is, however, much cheaper than the giant lookup table! [2] The point is that both code and data have value, but they have different values when applied to different problems. Your goal is *use both of them in order to solve problems for a minimal cost* (& with a maximal probability of success!). Both code and data are valuable tools that we can use to solve problems. It is only their interpretation by humans and the way they are used by humans that determines if they are a good tool or bad tool for a given problem. Also, keep in mind that most problems are best solved by using *many* tools in different ways and in different amounts. Our job is to find the optimal combination of all the possible choices. Alan [1] Of course, the currently executing code may modify data, which is then executed later. Hence we have assemblers, compilers, macros, etc. [2] Notice that both the lookup table "data" and the addition recipe "code" were delivered to you as ink on paper, analogous to the computer where both data and code are expressed as bytes. On Tue, Feb 2, 2016 at 9:37 AM, Frank Castellucci <frankiec...@gmail.com> wrote: > Josh > > To assume there is/was a problem because someone said so will waste your > time. Through all the religious zealotry and opposing opinions, my comment > would be: > > "Eschew commentary. View each technology option as a tool in your > tool-belt, and expand it as time goes on. When the right problem comes > along, using the right tool regardless of politics will get the job done > right" > > > On Monday, February 1, 2016 at 5:02:23 PM UTC-5, Josh Tilles wrote: >> >> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: >> Distributed Computing for Clojure” >> <https://youtube.com/watch?v=YlfA8hFs2HY&t=734>, I'm distracted by a >> nagging worry that we —as a community— are somehow falling into the same >> trap as the those advocating XML in the early 2000s. That said, it's a very >> *vague* unease, because I don’t know much about why the industry seems >> to have rejected XML as “bad”; by the time I started programming >> professionally there was already a consensus that XML sucked, and that >> libraries/frameworks that relied heavily on XML configuration files were to >> be regarded with suspicion and/or distaste. >> >> So, am I incorrect in seeing a similarity between the “data > code” >> mentality and the rise of XML? Or, assuming there is a legitimate >> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use >> edn instead of XML sidestep everything that went wrong in the 2000s? Or is >> it the case that the widespread backlash against XML threw a baby out with >> the bathwater, forgetting the advantages of data over code? >> >> Cheers, >> Josh >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
