Metamine was a language that appeared here on HN a few times, but seems to have disappeared. The thing that made it interesting is that it let you mix imperative and declarative code in the same program. It did this with a "magical equals", after executing it once, the left side auto-updated outside the flow of the imperative code.
= magical equals, which maintains the relation for the rest of the runtime
note: once you use it on a variable, you can't redefine it later, that's an error
:= normal assignment, which only fires once
Sadly the video is no longer available. Seems like they were anticipating signals. I can see some real opportunity for confusion though, I would see the magic equals as invariants defined outside the flow of code, as mixing them into control flows could lead to lots madcap laughs so to speak.
Perhaps you may find like-minded folks in the functional-thinking community:
I was trying to figure out what you meant by "declarative" because CSS is declarative. (My understanding is: "declarative means you say (declare) what you want, but not how to get it." Usually SQL is the poster child of declarative languages.)
I think you're really talking about a mix of preferring data (vs actions/calculations) and DSLs (which aren't necessarily declarative)
Eric Normand has some thoughts you might appreciate:
I think data can be very powerful. For example, someone explained to me:
> I've been helping my non-tech father with Home Assistant. I've honestly been shocked with how far "community extensions" + "user configuration" can take you. Every time we hit a bug, I go "time to hit github" but without fail chatgpt and him are able to tweak a setting to get it working.
If you make your system configurable (config==data), you can skip the whole compile/build step!
Re: CSS, it is indeed declarative, that was a bit sloppy of me. My comparison rests on observed difficulties. Valid CSS can contain duplicates, overwrites, or coupled parent-child pairs as in a grid, or mistaken use of properties that have no effect without other properties. CSS allows disciplined decomposition and separation of concerns, but does not enforce it. We all seem to agree this is the RightThing(tm), but it means CSS fails on practical grounds when compared to, for example, SQL DDL. Disciplined use of DDL is baked in, in CSS it must be enforced and requires decisions on how to do so.
It may be easier to describe "what I'm really talking about" by going more concrete. For a browser app, we have two declarative languages and one imperative. A tool like React with jsx allows me to think entirely in terms of code, folding the HTML into code, and tying off CSS to be dealt with on its own. It's a delightful simplification at first glance, that happens to leak like a sieve and forces people to become React programmers instead of browser programmers. I tend to think it is successful because it lets us think in terms of telling the computer to do things, and imposes no required mental model on how you craft your components. React says, "make it more imperative, use more code, think of your HTML in terms of code."
So I go the other way, where I add data binding attributes to HTML. A server request that modifies data always gets a response in terms of data that a small bit of framework code uses to update the DOM according to the data bindings. It is highly constrained in the same sense as SQL, there is only a small fixed set of allowed operations.
This is what I mean by declarative. My HTML data binding attributes say what should be displayed, no app code required. Naturally there are more details, but that should make the idea clear. The driving motivation is performance and developer ergonomics. Performance is amazing. Ergonomics, I can't say - it's easy for me, but I wrote it.
But solutions like these do not gain traction usually. I believe it is because people prefer the open-ended nature of React, which does not require a mapping exercise into the supported patterns before it can be used.
This is probably what I was trying to say about declarative vs imperative. React does not constrain my choices (not at first glance), and allows me to mix declarative HTML into my code. I can write any code I want, and like an LLM, I can fix anything with more code. Declarative solutions, like my own HTML data binding attributes, constrain the user to fixed supported patterns, which may not map to how the programmer thinks of the problem.
Metamine was a language that appeared here on HN a few times, but seems to have disappeared. The thing that made it interesting is that it let you mix imperative and declarative code in the same program. It did this with a "magical equals", after executing it once, the left side auto-updated outside the flow of the imperative code.
The demo was pretty fun to watch.[1][1] http://web.archive.org/web/20201014024057/https://www.youtub...
Sadly the video is no longer available. Seems like they were anticipating signals. I can see some real opportunity for confusion though, I would see the magic equals as invariants defined outside the flow of code, as mixing them into control flows could lead to lots madcap laughs so to speak.
Perhaps you may find like-minded folks in the functional-thinking community:
I was trying to figure out what you meant by "declarative" because CSS is declarative. (My understanding is: "declarative means you say (declare) what you want, but not how to get it." Usually SQL is the poster child of declarative languages.)
I think you're really talking about a mix of preferring data (vs actions/calculations) and DSLs (which aren't necessarily declarative)
Eric Normand has some thoughts you might appreciate:
- How a problem might take 1000 SLOC to solve directly, but only 10 SLOC with a DSL (plus up to 500 SLOC for the DSL itself; still fewer lines total) https://ericnormand.me/podcast/magical-leverage-languages
- Data vs calculations vs actions: https://ericnormand.me/podcast/what-is-an-action
---
I think data can be very powerful. For example, someone explained to me:
> I've been helping my non-tech father with Home Assistant. I've honestly been shocked with how far "community extensions" + "user configuration" can take you. Every time we hit a bug, I go "time to hit github" but without fail chatgpt and him are able to tweak a setting to get it working.
If you make your system configurable (config==data), you can skip the whole compile/build step!
Re: CSS, it is indeed declarative, that was a bit sloppy of me. My comparison rests on observed difficulties. Valid CSS can contain duplicates, overwrites, or coupled parent-child pairs as in a grid, or mistaken use of properties that have no effect without other properties. CSS allows disciplined decomposition and separation of concerns, but does not enforce it. We all seem to agree this is the RightThing(tm), but it means CSS fails on practical grounds when compared to, for example, SQL DDL. Disciplined use of DDL is baked in, in CSS it must be enforced and requires decisions on how to do so.
It may be easier to describe "what I'm really talking about" by going more concrete. For a browser app, we have two declarative languages and one imperative. A tool like React with jsx allows me to think entirely in terms of code, folding the HTML into code, and tying off CSS to be dealt with on its own. It's a delightful simplification at first glance, that happens to leak like a sieve and forces people to become React programmers instead of browser programmers. I tend to think it is successful because it lets us think in terms of telling the computer to do things, and imposes no required mental model on how you craft your components. React says, "make it more imperative, use more code, think of your HTML in terms of code."
So I go the other way, where I add data binding attributes to HTML. A server request that modifies data always gets a response in terms of data that a small bit of framework code uses to update the DOM according to the data bindings. It is highly constrained in the same sense as SQL, there is only a small fixed set of allowed operations.
This is what I mean by declarative. My HTML data binding attributes say what should be displayed, no app code required. Naturally there are more details, but that should make the idea clear. The driving motivation is performance and developer ergonomics. Performance is amazing. Ergonomics, I can't say - it's easy for me, but I wrote it.
But solutions like these do not gain traction usually. I believe it is because people prefer the open-ended nature of React, which does not require a mapping exercise into the supported patterns before it can be used.
This is probably what I was trying to say about declarative vs imperative. React does not constrain my choices (not at first glance), and allows me to mix declarative HTML into my code. I can write any code I want, and like an LLM, I can fix anything with more code. Declarative solutions, like my own HTML data binding attributes, constrain the user to fixed supported patterns, which may not map to how the programmer thinks of the problem.