3 ms·

> I understand how to read code. Funny, I still have no idea how to do this after decades of trying. I constantly run into functions called doSomething that al

> I understand how to read code. Funny, I still have no idea how to do this after decades of trying. I constantly run into functions called doSomething that also do something else. LP is absolutely not about teaching the language while teaching a codebase, and this is something LP does get right independent of my criticisms here.

bluGill 2y ago
> I constantly run into functions called doSomething that also do something else. You have to have some trust in your fellow coders that doSomething doesn't do something else and this is often false. Still in most cases it doesn't matter on a first read as doSomething is close enough to only doing that something. LP won't help here anyway. Documentation can be wrote just as much as the function name. You say LP is not about teaching the language, but the examples from Knuth himself are often documenting the language and not the codebase. This is a common problem with documentation.
- akkartik 2y ago
  As people repeatedly say in trying to rebut my OP, it's important not to cherry-pick examples. I try to be careful to find the best examples when criticizing. In that spirit, here's a couple of examples from https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs/hwtime.w https://cs.stanford.edu/~knuth/programs/hwtime.w is the very first, and most easy to justify introducing a language, but it doesn't do much of that. It does your thing of explaining stdio. A slightly more advanced example https://cs.stanford.edu/~knuth/programs/hull.w https://cs.stanford.edu/~knuth/programs/hull.w doesn't explain #includes, and doesn't describe the language as far as I can see/recall. So feel free to share examples where people document the language. But that doesn't feel like a big anti-pattern to me.

bluGill 2y ago

> I constantly run into functions called doSomething that also do something else. You have to have some trust in your fellow coders that doSomething doesn't do something else and this is often false. Still in most cases it doesn't matter on a first read as doSomething is close enough to only doing that something. LP won't help here anyway. Documentation can be wrote just as much as the function name. You say LP is not about teaching the language, but the examples from Knuth himself are often documenting the language and not the codebase. This is a common problem with documentation.

akkartik 2y ago
As people repeatedly say in trying to rebut my OP, it's important not to cherry-pick examples. I try to be careful to find the best examples when criticizing. In that spirit, here's a couple of examples from https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs/hwtime.w https://cs.stanford.edu/~knuth/programs/hwtime.w is the very first, and most easy to justify introducing a language, but it doesn't do much of that. It does your thing of explaining stdio. A slightly more advanced example https://cs.stanford.edu/~knuth/programs/hull.w https://cs.stanford.edu/~knuth/programs/hull.w doesn't explain #includes, and doesn't describe the language as far as I can see/recall. So feel free to share examples where people document the language. But that doesn't feel like a big anti-pattern to me.