3 ms·

Ah, I see what you're saying. (Links for any others reading: https://akkartik.github.io/mu1/html/010vm.cc.html#L606 https://akkartik.github.io/mu1/html/010vm.cc

Ah, I see what you're saying. (Links for any others reading: https://akkartik.github.io/mu1/html/010vm.cc.html#L606 https://akkartik.github.io/mu1/html/010vm.cc.html#L606 and https://akkartik.github.io/mu1/html/014literal_string.cc.html#L121 https://akkartik.github.io/mu1/html/014literal_string.cc.htm...) I should have been more hygienic in this old prototype. But honestly this idea of a waypoint being a hint is something I just thought up. Mostly my mindset is that layers should be oblivious to later layers. Ditto for readers; the goal is for you to not have to worry about later layers when you're reading a simple version. > My initial reaction is that it just moves the complexity around a bit, without really helping much. From OP: "We aren't just reordering bits here. There's a new constraint that has no counterpart in current programming practice — remove a feature, and everything before it should build and pass its tests." If this doesn't seem valuable, I probably can't persuade you. In general I've grown a lot less concerned about how code looks and a lot more concerned about having lots of different runnable versions of a single program that a reader can play around with to build up an instinct for it. Each unit test in a program is conceptually a distinct runnable version. Layers push further in that direction.

magicalhippo 7y ago
When I read your rationale, it feels a lot like literal programming, as I experienced it when reading PBR[1]. But without the documentation around it, I'm not sure I feel the same way about it. It feels harder to reason about what where why. Also, I'm assuming bugs should be fixed without using this layering. After all, without that layer you got broken code. But often I find there's not a clear-cut distinction between feature and bug fix. What then? Anyway, interesting idea, would have to try it to get a feel like I said. [1]: For example http://www.pbr-book.org/3ed-2018/Sampling_and_Reconstruction/Sampling_Interface.html#BasicSamplerInterface http://www.pbr-book.org/3ed-2018/Sampling_and_Reconstruction...
- akkartik 7y ago
  It's definitely inspired by Literate Programming. My code instructions in OP refer to a directory called wart/literate. > But without the documentation around it, I'm not sure I feel the same way about it. It feels harder to reason about what where why. I don't understand this. Are you saying my approach doesn't permit documentation? I don't see why. Check out the start of the first layer: http://akkartik.github.io/mu/html/000organization.cc.html http://akkartik.github.io/mu/html/000organization.cc.html Do you mean that the documentation doesn't look as nice as Literate systems? I think that's a good thing: http://akkartik.name/post/literate-programming http://akkartik.name/post/literate-programming. Giving important concepts in your program a good central place is the essential need of documentation. Layers give features a single consolidated place (a https://en.wikipedia.org/wiki/Focal_point_(game_theory) https://en.wikipedia.org/wiki/Focal_point_(game_theory) ) where you can include documentation and be confident that someone interested in the feature will find it. Next to this attribute, I think typography is almost meaningless. I think it's far more important that documentation be accessible from within my programming environment, than that it be typeset well. > I'm assuming bugs should be fixed without using this layering. Yup! From the final paragraph of OP: "Codebases have three kinds of changes: bugfixes, new features and reorganizations. In my new organization bugfixes modify a single layer.."

magicalhippo 7y ago

When I read your rationale, it feels a lot like literal programming, as I experienced it when reading PBR[1]. But without the documentation around it, I'm not sure I feel the same way about it. It feels harder to reason about what where why. Also, I'm assuming bugs should be fixed without using this layering. After all, without that layer you got broken code. But often I find there's not a clear-cut distinction between feature and bug fix. What then? Anyway, interesting idea, would have to try it to get a feel like I said. [1]: For example http://www.pbr-book.org/3ed-2018/Sampling_and_Reconstruction/Sampling_Interface.html#BasicSamplerInterface http://www.pbr-book.org/3ed-2018/Sampling_and_Reconstruction...

akkartik 7y ago
It's definitely inspired by Literate Programming. My code instructions in OP refer to a directory called wart/literate. > But without the documentation around it, I'm not sure I feel the same way about it. It feels harder to reason about what where why. I don't understand this. Are you saying my approach doesn't permit documentation? I don't see why. Check out the start of the first layer: http://akkartik.github.io/mu/html/000organization.cc.html http://akkartik.github.io/mu/html/000organization.cc.html Do you mean that the documentation doesn't look as nice as Literate systems? I think that's a good thing: http://akkartik.name/post/literate-programming http://akkartik.name/post/literate-programming. Giving important concepts in your program a good central place is the essential need of documentation. Layers give features a single consolidated place (a https://en.wikipedia.org/wiki/Focal_point_(game_theory) https://en.wikipedia.org/wiki/Focal_point_(game_theory) ) where you can include documentation and be confident that someone interested in the feature will find it. Next to this attribute, I think typography is almost meaningless. I think it's far more important that documentation be accessible from within my programming environment, than that it be typeset well. > I'm assuming bugs should be fixed without using this layering. Yup! From the final paragraph of OP: "Codebases have three kinds of changes: bugfixes, new features and reorganizations. In my new organization bugfixes modify a single layer.."