Data is code
18 points by veqq
18 points by veqq
Meta: no Forth or concatenative tag, but in the future hopefully search will find it via this.
Forth makes an argument that most of the data that your program deals with is actually about controlling what your program should do, and making decisions about what your program should do is the job of code.
This deeply resonated with my perspective working w/ Lisps.
I have not used Forth before, and I’m having trouble piecing above paragraph with the note below:
it’s also trivial for me to add little custom setpieces to a given level… I have the full power of the language at my disposal. If I’d taken a data-driven approach, I would have needed to plan everything in advance, to design my little problem-oriented VM and and hope I thought of everything I needed. But with a code-first approach, I can be much more exploratory – try to build things, and if they work well, factor them out to be used more generally. Architecture arises naturally from need, as I build.
I feel that I have this experience in Lisps as well - the ability to extend the language incrementally and let architecture emerge from use. While the mechanics differ (Lisp transforming s-expressions vs Forth defining new words), both approaches seem to enable bottom-up, exploratory programming. I’d be curious if any experienced Forth programmers could illustrate what makes Forth’s “data is code” approach fundamentally different from Lisp’s “code is data” in practice?
I think this is about the other part. The idea that something passed as passive data can turn out to carry active code attached is closer to writing everything in multiple-dispatch object-oriented code (in Common Lisp some of the basic functionality might need wrapping, in something like Julia you get methods by default) then defining special methods saying that some operation for a specific subclass is defined differently.