3 ms·

Your fundamental flaw is my prized feature. Metaprogramming/reflection would be impossible without treating code as content.

by ukj 5y ago

lisper 5y ago
And this tension in goals is not limited to software. Modifying and repairing hardware is similarly fraught. You can get yourself into all kinds of trouble by tinkering with (say) your car. The real difference is that you generally have to be in physical proximity to hardware in order to tinker with it, and that puts a very hard constraint on random people mucking with your car. Not so for software, especially in the age of the internet.
lucian1900 5y ago
Not at all, even in Lisps there’s quoting. In-band signalling isn’t necessary for either meta programming or reflection.
- ukj 5y ago
  Signalling is the same thing as mutability. To signal is to flip a bit. If code is data and data is immutable then code is immutable. I am sure you see the contradiction in objectives.
- ukj 5y ago
  Saying the same thing from yet another perspective: What you call in-band - I call data. What you call out-of-band - I call code. What I call metaprogramming is erasing the distinction.
schwag09 5y ago
Let me rephrase, I think it's often a fundamental flaw from a practical, security perspective. Reflection and constructs like 'eval' are often at odds with security. You could more generally say that utility is often at odds with security. Maximizing utility on a website might look like dropping a user into a root REPL so they can perform arbitrary actions and are unlimited in their capabilities. Maximizing security might look like shutting down the website and all its associated servers. In reality, from a security perspective, we try to achieve a balance between the two by maximizing utility while minimizing security risk. Personally, I think code as content, reflection, eval, etc move the slider too far in the utility direction. Of course this is a difficult problem to solve because nearly all our systems are built on the idea of code as content, which is also what makes it such a generalized vulnerability class.

Your fundamental flaw is my prized feature. Metaprogramming/reflection would be impossible without treating code as content.

by ukj 5y ago

Your fundamental flaw is my prized feature. Metaprogramming/reflection would be impossible without treating code as content.

lisper 5y ago

And this tension in goals is not limited to software. Modifying and repairing hardware is similarly fraught. You can get yourself into all kinds of trouble by tinkering with (say) your car. The real difference is that you generally have to be in physical proximity to hardware in order to tinker with it, and that puts a very hard constraint on random people mucking with your car. Not so for software, especially in the age of the internet.

lucian1900 5y ago

Not at all, even in Lisps there’s quoting. In-band signalling isn’t necessary for either meta programming or reflection.

ukj 5y ago
Signalling is the same thing as mutability. To signal is to flip a bit. If code is data and data is immutable then code is immutable. I am sure you see the contradiction in objectives.
ukj 5y ago
Saying the same thing from yet another perspective: What you call in-band - I call data. What you call out-of-band - I call code. What I call metaprogramming is erasing the distinction.

schwag09 5y ago

Let me rephrase, I think it's often a fundamental flaw from a practical, security perspective. Reflection and constructs like 'eval' are often at odds with security. You could more generally say that utility is often at odds with security. Maximizing utility on a website might look like dropping a user into a root REPL so they can perform arbitrary actions and are unlimited in their capabilities. Maximizing security might look like shutting down the website and all its associated servers. In reality, from a security perspective, we try to achieve a balance between the two by maximizing utility while minimizing security risk. Personally, I think code as content, reflection, eval, etc move the slider too far in the utility direction. Of course this is a difficult problem to solve because nearly all our systems are built on the idea of code as content, which is also what makes it such a generalized vulnerability class.