4 ms·

One claim that caught my eye: Tex being unbuggy because it's written in the Literate Programming style. I like LP but that's a big claim. Occam's razor suggests

One claim that caught my eye: Tex being unbuggy because it's written in the Literate Programming style. I like LP but that's a big claim. Occam's razor suggests a more likely answer: it was written by Knuth! A great programmer, and also one who grew up programming non-interactively: http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7 http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7

deathanatos 8y ago
On the one hand, I see your point. But on the other hand, if a master of some skill says "This is how I achieve the results I achieve." — perhaps imitating that might just be valuable. Does a dancer not get better by learning to imitate (at least at first) a master? (Though perhaps eventually, a deeper understanding of the artform might take hold, at which point experimentation and improvisation allow the dancer to explore undiscovered variations of the artform.) And I don't think it is just that Knuth does it that catches my attention either. Ideally, I think (if I understand the premise of literate programming), literate programming would force the programmer to take the time to explain the code being written, and ideally, the rationale behind why that code solves the problem at hand. And to do that, the programmer must first understand the code being written, and I think upon attempting to do that, they'll find they have not sufficiently thought the problem through. I fear too many of the coders I know would not honestly attempt it; they are in too much of a hurry to get the code written. Now, I don't think literate programming is the only way to accomplish that; simply writing good docstrings and comments might suffice to a good degree (and good ones: I too often review code where the docstring is a basic repetition of the function name and arguments, or where the comments explain what is being done, but not why). But far too often I see no comments, no docstrings, no tests, just miles and miles of code, and so it is no wonder that Knuth is what he is.
- akkartik 8y ago
  No disagreement there! Though you may violently agree or disagree with this thing I wrote a couple of years ago: http://akkartik.name/post/literate-programming http://akkartik.name/post/literate-programming I also just looked at your profile, and it resonates a lot. Tell me what you think of mine: http://akkartik.name/post/about http://akkartik.name/post/about
  - svat 8y ago
    I'm not the person you're replying to, but I think you mean http://akkartik.name/about http://akkartik.name/about (and not http://akkartik.name/post/about http://akkartik.name/post/about). And though you didn't ask me, I read it (having been annoyed by your LP post for a few years now) and it strongly resonates with me — the mission, and everything until the start of the “Constraints on a solution” section. IMO the way to give more people more understanding of programs is not to write an entire new programming language / operating system and hope that enough people switch to it, but to work on delivering that “understanding” for existing programs in existing languages. It may be harder, but is more likely to be useful, and you also get feedback on what kind of understanding people want and lack.
    - akkartik 8y ago
      Many thanks for the correction, and for the comment! It is absolutely likely that delivering the understanding for existing programs is the way to go. Unfortunately I just don't know enough for that yet. It's a hard chicken-and-egg problem: to understand the current stack I need precisely the concepts and tools that I'm trying to work out. Over the last few years I've switched back and forth between the two extremes. I spent a couple of years off and on learning how operating systems (OpenBSD, Sortix, a little bit of Linux) work. I've gained some hard-won facility for poking around inside GNU package sources. So it's yet possible that I'll find a way to make progress on an existing stack. It also depends what the criterion for 'success' is when we consider this "strike out vs work within" tradeoff. If the goal is some level of adoption then it's a no-brainer that working with existing platforms is the way to go. But I may be content just to figure out the right answer for myself. Working within an existing platform requires a time commitment to a single (or a tiny subset) of the many projects that our platforms have balkanized into. After all that time commitment, effecting change from within requires a level of politics that is definitely not my strong suit. These projects have real users and justifiably shouldn't be giving me the time of day anytime soon. One alternative I've considered is forking a mature platform. It remains on my radar, but at the moment I think the drop-off in benefits the instant I hit 'fork' is way too great. Consider a platform like OpenBSD that frankly is created by way smarter people than myself and is way more mature. The level of adoption it gets from being POSIX compliant is so miniscule; would making incompatible changes really be that counter-productive? It's worth asking if you're baiting big to catch small. On some level my real target is to change the customs that influence how open source projects are governed. Even if I managed to overcome all the previous hurdles, it still seems impossible within the existing framework to do things like encourage more forks in projects, or convince more people to cull their dependencies, or read their sources. There's just too much baggage. Starting afresh may paradoxically make a new way easier to see. This is the "idea maze" as I see it. I'd love to hear more, what you think of it.
emmanueloga_ 8y ago
Reading TeX original source is easier said than done... I think I managed to get PDF some time ago but took me like 30 minutes of browsing. Not talk about running it...
- svat 8y ago
  It's available as a book (TeX: The Program, volume B of Computers and Typesetting), and Knuth considers the book as the canonical thing to read. You almost surely don't have a PDF of the entire book, but it's easily available in good libraries: http://www.worldcat.org/title/tex-the-program/oclc/826569131 http://www.worldcat.org/title/tex-the-program/oclc/826569131 (or you can buy it: as I was typing this comment I just finally bought a used copy from Amazon for $9 which is pretty good for a hardcover book). If you have a typical TeX distribution installed, you can see an approximation by running `texdoc tex`, which brings up the PDF that is also available online e.g. here: http://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf http://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf -- but it is a bit hard to make sense of if you're not familiar with the conventions of WEB (the book starts with a "How to read a WEB") -- as a workaround maybe you can read webman (http://texdoc.net/texmf-dist/doc/generic/knuth/web/webman.pdf http://texdoc.net/texmf-dist/doc/generic/knuth/web/webman.pd...) though that's meant for the programmer (working with the raw .web files) rather than the reader (working with the typeset output). And it helps to be familiar with Pascal, and the typical conventions of programming style in the 1970s (e.g. that of the P4 (Pascal) Compiler and Interpreter, also published as a book and also available online: https://homepages.cwi.nl/~steven/pascal/ https://homepages.cwi.nl/~steven/pascal/ ) I've been reading the TeX program in bits and pieces for over a year now, and only now do I have a rough sense of it all :-)
  - emmanueloga_ 8y ago
    Cool, very informative! The bad thing about a print book is that you would have to type the code to run it... How would you go about running TeX? I find the most effective way to read source code is to run it (to answer questions like: "what's the output if the input is this thing", etc.) I wish someone who's familiar with the moving pieces would put together a version that runs on a browser.

deathanatos 8y ago

On the one hand, I see your point. But on the other hand, if a master of some skill says "This is how I achieve the results I achieve." — perhaps imitating that might just be valuable. Does a dancer not get better by learning to imitate (at least at first) a master? (Though perhaps eventually, a deeper understanding of the artform might take hold, at which point experimentation and improvisation allow the dancer to explore undiscovered variations of the artform.) And I don't think it is just that Knuth does it that catches my attention either. Ideally, I think (if I understand the premise of literate programming), literate programming would force the programmer to take the time to explain the code being written, and ideally, the rationale behind why that code solves the problem at hand. And to do that, the programmer must first understand the code being written, and I think upon attempting to do that, they'll find they have not sufficiently thought the problem through. I fear too many of the coders I know would not honestly attempt it; they are in too much of a hurry to get the code written. Now, I don't think literate programming is the only way to accomplish that; simply writing good docstrings and comments might suffice to a good degree (and good ones: I too often review code where the docstring is a basic repetition of the function name and arguments, or where the comments explain what is being done, but not why). But far too often I see no comments, no docstrings, no tests, just miles and miles of code, and so it is no wonder that Knuth is what he is.

akkartik 8y ago
No disagreement there! Though you may violently agree or disagree with this thing I wrote a couple of years ago: http://akkartik.name/post/literate-programming http://akkartik.name/post/literate-programming I also just looked at your profile, and it resonates a lot. Tell me what you think of mine: http://akkartik.name/post/about http://akkartik.name/post/about
- svat 8y ago
  I'm not the person you're replying to, but I think you mean http://akkartik.name/about http://akkartik.name/about (and not http://akkartik.name/post/about http://akkartik.name/post/about). And though you didn't ask me, I read it (having been annoyed by your LP post for a few years now) and it strongly resonates with me — the mission, and everything until the start of the “Constraints on a solution” section. IMO the way to give more people more understanding of programs is not to write an entire new programming language / operating system and hope that enough people switch to it, but to work on delivering that “understanding” for existing programs in existing languages. It may be harder, but is more likely to be useful, and you also get feedback on what kind of understanding people want and lack.
  - akkartik 8y ago
    Many thanks for the correction, and for the comment! It is absolutely likely that delivering the understanding for existing programs is the way to go. Unfortunately I just don't know enough for that yet. It's a hard chicken-and-egg problem: to understand the current stack I need precisely the concepts and tools that I'm trying to work out. Over the last few years I've switched back and forth between the two extremes. I spent a couple of years off and on learning how operating systems (OpenBSD, Sortix, a little bit of Linux) work. I've gained some hard-won facility for poking around inside GNU package sources. So it's yet possible that I'll find a way to make progress on an existing stack. It also depends what the criterion for 'success' is when we consider this "strike out vs work within" tradeoff. If the goal is some level of adoption then it's a no-brainer that working with existing platforms is the way to go. But I may be content just to figure out the right answer for myself. Working within an existing platform requires a time commitment to a single (or a tiny subset) of the many projects that our platforms have balkanized into. After all that time commitment, effecting change from within requires a level of politics that is definitely not my strong suit. These projects have real users and justifiably shouldn't be giving me the time of day anytime soon. One alternative I've considered is forking a mature platform. It remains on my radar, but at the moment I think the drop-off in benefits the instant I hit 'fork' is way too great. Consider a platform like OpenBSD that frankly is created by way smarter people than myself and is way more mature. The level of adoption it gets from being POSIX compliant is so miniscule; would making incompatible changes really be that counter-productive? It's worth asking if you're baiting big to catch small. On some level my real target is to change the customs that influence how open source projects are governed. Even if I managed to overcome all the previous hurdles, it still seems impossible within the existing framework to do things like encourage more forks in projects, or convince more people to cull their dependencies, or read their sources. There's just too much baggage. Starting afresh may paradoxically make a new way easier to see. This is the "idea maze" as I see it. I'd love to hear more, what you think of it.

emmanueloga_ 8y ago

Reading TeX original source is easier said than done... I think I managed to get PDF some time ago but took me like 30 minutes of browsing. Not talk about running it...

svat 8y ago
It's available as a book (TeX: The Program, volume B of Computers and Typesetting), and Knuth considers the book as the canonical thing to read. You almost surely don't have a PDF of the entire book, but it's easily available in good libraries: http://www.worldcat.org/title/tex-the-program/oclc/826569131 http://www.worldcat.org/title/tex-the-program/oclc/826569131 (or you can buy it: as I was typing this comment I just finally bought a used copy from Amazon for $9 which is pretty good for a hardcover book). If you have a typical TeX distribution installed, you can see an approximation by running `texdoc tex`, which brings up the PDF that is also available online e.g. here: http://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf http://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf -- but it is a bit hard to make sense of if you're not familiar with the conventions of WEB (the book starts with a "How to read a WEB") -- as a workaround maybe you can read webman (http://texdoc.net/texmf-dist/doc/generic/knuth/web/webman.pdf http://texdoc.net/texmf-dist/doc/generic/knuth/web/webman.pd...) though that's meant for the programmer (working with the raw .web files) rather than the reader (working with the typeset output). And it helps to be familiar with Pascal, and the typical conventions of programming style in the 1970s (e.g. that of the P4 (Pascal) Compiler and Interpreter, also published as a book and also available online: https://homepages.cwi.nl/~steven/pascal/ https://homepages.cwi.nl/~steven/pascal/ ) I've been reading the TeX program in bits and pieces for over a year now, and only now do I have a rough sense of it all :-)
- emmanueloga_ 8y ago
  Cool, very informative! The bad thing about a print book is that you would have to type the code to run it... How would you go about running TeX? I find the most effective way to read source code is to run it (to answer questions like: "what's the output if the input is this thing", etc.) I wish someone who's familiar with the moving pieces would put together a version that runs on a browser.