4 ms·

Almost every time I try to reach to meta-programming, on second thought, I found out that writing a method was the simpler way. I'm not a LISP expert, but IMO,

Almost every time I try to reach to meta-programming, on second thought, I found out that writing a method was the simpler way. I'm not a LISP expert, but IMO, if you're not building a library, meta-programming is an exotic paradigm. And that's because you're defining a new language, not adding new words in a dictionary. I think it's quite nice if you're building tooling though. Like creating a web framework to write web apps, or translating business queries to SQL. Writing imperative code always felt like transporting buckets of water. But CL (and other functional languages) feels like building a pipe system. Much more knowledge required upfront, but getting nicer the further you progress. ADDED: That's why there are so many frameworks, especially in the web dev world. It's nice to have someone carry the buckets to your room, even though you need to get it inside. The trouble starts when you want water somewhere not serviced. You have to figure the service routes to take it of at the most convenient place.

citizen_friend 2y ago
For typical projects you just need a handful. In other programming languages that means code generation or macro hell. So it is nice that it’s built into the language to do it properly, even if you only use it for those few things.
lispm 2y ago
Let's imagine we want to program some kind of state machine machinery. We can ask ourselves questions: what should it do? how should it work? what kind of features would it need to provide? From what parts would we like to build it? How can we integrate it into the programming language we use? How can we make it fast? How can we deal with errors? There is a question we haven't been asking yet: how do we want to write them down? What would be a compact notation, verifiable for a state machine? That's something which one can ask very early in Lisp: How should my code look like? How can I make sure I understand the state machine itself (not the low-level programming) months, years later and make changes to it? One way to answer that would be to add a syntax extension for state machines to Lisp. That would be embedded into the language. One can experiment with that, without the need to write too complex scanner&parser combinations. Just write the state machine as a list of state descriptions. A macro could transform it at compile-time into (efficient) low-level operations.

citizen_friend 2y ago

For typical projects you just need a handful. In other programming languages that means code generation or macro hell. So it is nice that it’s built into the language to do it properly, even if you only use it for those few things.

lispm 2y ago

Let's imagine we want to program some kind of state machine machinery. We can ask ourselves questions: what should it do? how should it work? what kind of features would it need to provide? From what parts would we like to build it? How can we integrate it into the programming language we use? How can we make it fast? How can we deal with errors? There is a question we haven't been asking yet: how do we want to write them down? What would be a compact notation, verifiable for a state machine? That's something which one can ask very early in Lisp: How should my code look like? How can I make sure I understand the state machine itself (not the low-level programming) months, years later and make changes to it? One way to answer that would be to add a syntax extension for state machines to Lisp. That would be embedded into the language. One can experiment with that, without the need to write too complex scanner&parser combinations. Just write the state machine as a list of state descriptions. A macro could transform it at compile-time into (efficient) low-level operations.