3 added 21 characters in body
source | link

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs to the remote system ahead of time, install them, execute them, and then send your data.

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs ahead of time, install them, execute them, and then send your data.

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs to the remote system ahead of time, install them, execute them, and then send your data.

2 added 44 characters in body
source | link

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

But you could just as easily do this with any other programming language, including Lisp. AllSo all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs ahead of time, install them, execute them, and then send your data.

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

But you could just as easily do this with any other programming language, including Lisp. All you do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs ahead of time, install them, execute them, and then send your data.

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs ahead of time, install them, execute them, and then send your data.

1
source | link

I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
    <arguments>
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
    </arguments>
    <body>
        <return>
            <add value1="arg1" value2="arg2" />
        </return>
    </body>
</define>

But you could just as easily do this with any other programming language, including Lisp. All you do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs ahead of time, install them, execute them, and then send your data.