I don’t think this makes much sense. A lot of the time people create these abstractions because they need them.
We started speccing Markdown, the example given, not for aesthetics or a sense of cleanliness. We did it to add portability. We wanted lots of different systems to be able to deterministically produce the same result given the same Markdown. The benefit gained is that Markdown is a format you write your content in and move around.
Maybe we shouldn’t have tried to use a poorly specced thing as a format for html but it grew organically and became the lingua franca for markup. Why shouldn’t you just build on that?
I didn’t mean to dissuade people to do that re markdown. That’s fine and has been done successfully again and agian like at Reddit and Stack Exchange, and here. (I wish they would make asterisk be b and i in that case instead of strong and em.)
What I mean is that what the original Markdown was a good design pattern to follow as a deliberately “leaky abstraction”.
I’m a big fan of leaky abstractions > incomplete abstractions
There are exceptions to this rule like every rule, but I’ve been thinking a lot about it working on my compile-to-js language.
At first i created my own standard library & data structures (immutable) as well as a modified object system.. but over time i scrapped it because i want to be highly compatible with web apis & its future.
Its turning out to make the language significantly simpler & actually more beautiful in my eyes.
Interesting idea, but calling “user inputs” a format is a stretch. FRP sort of does this by treating them as a kind of stream, but even then the contents of that stream are so contextual, it’s not really a format in the same way that, say, CSV or glTF is a format.
I don’t think this makes much sense. A lot of the time people create these abstractions because they need them.
We started speccing Markdown, the example given, not for aesthetics or a sense of cleanliness. We did it to add portability. We wanted lots of different systems to be able to deterministically produce the same result given the same Markdown. The benefit gained is that Markdown is a format you write your content in and move around.
Maybe we shouldn’t have tried to use a poorly specced thing as a format for html but it grew organically and became the lingua franca for markup. Why shouldn’t you just build on that?
I didn’t mean to dissuade people to do that re markdown. That’s fine and has been done successfully again and agian like at Reddit and Stack Exchange, and here. (I wish they would make asterisk be b and i in that case instead of strong and em.)
What I mean is that what the original Markdown was a good design pattern to follow as a deliberately “leaky abstraction”.
Nice post
I’m a big fan of leaky abstractions > incomplete abstractions
There are exceptions to this rule like every rule, but I’ve been thinking a lot about it working on my compile-to-js language.
At first i created my own standard library & data structures (immutable) as well as a modified object system.. but over time i scrapped it because i want to be highly compatible with web apis & its future.
Its turning out to make the language significantly simpler & actually more beautiful in my eyes.
Interesting idea, but calling “user inputs” a format is a stretch. FRP sort of does this by treating them as a kind of stream, but even then the contents of that stream are so contextual, it’s not really a format in the same way that, say, CSV or glTF is a format.
First version of the post called it “layers”; maybe I should edit it and change it back?
Or maybe an example?