5 ms·

Nobody has mentioned Knuth’s corpus of work in Pascal-Web for the TeX ecosystem. This is code written for an era where there wasn’t an ecosystem of libraries fo

by dhosek 4y ago

Nobody has mentioned Knuth’s corpus of work in Pascal-Web for the TeX ecosystem. This is code written for an era where there wasn’t an ecosystem of libraries for common tasks and even things like being able to access a file in random access order couldn’t be counted on. Even 7-bit ASCII couldn’t be counted on as a given (EBCDIC-based IBM mainframes were a significant element of the computing landscape still). Against all that, Knuth wrote code that could be ported to other systems (I first used TeX on an IBM mainframe running VM/CMS, then later on a VAX minicomputer running VMS, then on a PC with DOS, PC with OS/2, PC with Windows and now a Mac with OS X/MacOS. His presentation of code and internal documentation intermingled is something which I could see still being useful now, although sadly, literate programming seems all but dead now. I still go back to Knuth’s code to understand how to solve some problems on occasion even though it’s about 30 years since I last wrote a line of Pascal.

db48x 4y ago
I second the nomination. I too have found the TeX Book to be very readable.
- gjm11 4y ago
  Pedantic note, which I'm writing just in case anyone misunderstands your recommendation: "The TeXbook" is the user manual for TeX. It is not the same thing as the book containing the (literate-program) source code for TeX, which is called "TeX: the program". (Both are excellent, but in quite different ways, and someone looking for interesting code to read would likely be disappointed by the TeXbook, which doesn't contain that.)
  - db48x 4y ago
    You’re right! I had to go pull my copy off the shelf and check, but it really is TeX: The Program.
    - drfuchs 4y ago
      Make sure to check out the dedication!
ThomasBHickey 4y ago
Back in the day I worked quite a bit with Knuth's early SAIL (an extended Algol on the PDP-10) implementation of Metafont. They could have used some of the documentation the later WEB versions had as he tended to get tricky with squeezing everything out of the 36-bit words (which I was porting to a 32-bit word machine). But the code was an education and a joy to read well before he polished it for publication.
- dhosek 4y ago
  I’ve heard some wild things about the old SAIL stuff. I never had the chance to encounter it though. I got on the TeX train in 1985¹ with TeX82/MF84. AMS/TUG still were using the am* fonts for their publications. ⸻ 1. My very first exposure was DEK’s article “TeX and Metafont” in a copy of Dr Dobb’s Journal that was part of a trove my brothers got a hold of—and then in 1984 seeing someone in the IIT computer lab paging through a copy of The TeXbook, so when I found out that UIC had just installed TeX on their mainframe, I was one of the first people to use it there.
beardog 4y ago
I've been writing a literate multi-file program in Go and Copilot has been partially compensating for the lack of tooling support, especially since Copilot can infer from prose. I intend to make a post about my experience.
fzil 4y ago
> although sadly, literate programming seems all but dead now It seems alive and well in the data-science community to me. Look at jupyter notebooks if you aren't aware of what I am talking about.
- nesarkvechnep 4y ago
  It’s not really literate programming. It’s just editable/executable code intertwined with text. There’s no tangle and weave, or code reuse.
  - tlarkworthy 4y ago
    What about this https://observablehq.com/@tomlarkworthy/redis-backend-1 https://observablehq.com/@tomlarkworthy/redis-backend-1
    - nesarkvechnep 4y ago
      The same thing. I don’t see chunk reuse, nor the ability to generate standalone documentation or export the code to files. Have you seen actual literate programming documents? The Noweb tool’s page has examples.
      - aljungberg 4y ago
        Sounds like nbdev which indeed exports code and documentation from a single notebook, plus unit tests for external execution.
      - tlarkworthy 4y ago
        The imports are chunk reuse. Each notebook is an es6 module you can import from any npm package.json You don't need to export it as documentation, it is executable documentation which is better, though you can print it if you want. The footer backs up the source to github Your stuck on Knuth's definition of literate programming but this is better than that
- mellavora 4y ago
froh 4y ago
I think LSP language server protocol and literate programming are a match made in heaven. A simple syntax like noweb and a LSP dispatcher which only handles the noweb syntax elements and dispatches both text and code chunks to respective back ends; the LP LSP Server tangles the code chunks and presents the tangled code to the code specific LSP servers and does the mapping forth and back of the position-in-nw vs position-in-$code while passing all other communication through. especially now that we have DAP something like this would really make sense, wouldn't it?
- junon 4y ago
  Speaking anecdotally, I have nothing but issues with LSP. It's a pain to use, a pain to configure, gives sub-par results and is usually wraps with extra "features" that change how code gets edited between different languages (I know this is less LSP's fault). Not to dismiss the mountain of work people have put into it, but it feels very hacked together and clunky rather than a shining achievement.
  - tuukkah 4y ago
    Case in point, Microsoft develops an editor (VSCode) and LSP so that N*M language integrations wouldn't be necessary. But in the development of their language (TypeScript), LSP support is not a priority (in part because LSP is inadequate in its current form): https://github.com/microsoft/TypeScript/issues/39459 https://github.com/microsoft/TypeScript/issues/39459
    - codethief 4y ago
      > We're working on this, albeit slowly. tsserver's implementation predates LSP so it's nontrivial work to move forward in a way that doesn't adversely affect old clients or result in code duplication.
      - tuukkah 4y ago
        Good to hear you're still committed. By "not a priority" I mean we have been waiting since this was published back in 2016: "[LSP] also means any developer can have a consistent editing experience for their favorite programming language on any tool – even if that tool isn’t VS Code." https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol https://code.visualstudio.com/blogs/2016/06/27/common-langua... The original bug against Typescript was opened in 2016 as well: https://github.com/microsoft/TypeScript/issues/11274 https://github.com/microsoft/TypeScript/issues/11274
kzrdude 4y ago
With the sorry state of latex engine error messages and the version number still approximating pi, e, something, it is no longer an ideal to me. It represents stagnation. Being bug-free may be good, but at some point feature development is needed. (I know TeX and LaTeX are not the same)
- dhosek 4y ago
  There are some serious legacy issues with the LaTeX ecosystem. The lack of being able to version individual package dependencies for a document is a huge one. You’re at the mercy of lots of independent packages which often have complex webs of interdependency. Probably the biggest mistake was the choice to abandon the idea of having a LaTeX 3 version with its implicit breaking of backwards compatibility. Backwards compatibility means that there’s a tangle of fragility that only grows with time which is part of why the error messages are so frequently bad. Changes are a fraught proposition. This is part of what inspired my decision to start work on finl.
  - kzrdude 4y ago
    Best of luck
TanjB 4y ago
TeX was beautiful. Both the algorithms (it was a masterwork on typesetting, still a good reference for anyone doing text layout) and the book.

by dhosek 4y ago

db48x 4y ago

I second the nomination. I too have found the TeX Book to be very readable.

gjm11 4y ago
Pedantic note, which I'm writing just in case anyone misunderstands your recommendation: "The TeXbook" is the user manual for TeX. It is not the same thing as the book containing the (literate-program) source code for TeX, which is called "TeX: the program". (Both are excellent, but in quite different ways, and someone looking for interesting code to read would likely be disappointed by the TeXbook, which doesn't contain that.)
- db48x 4y ago
  You’re right! I had to go pull my copy off the shelf and check, but it really is TeX: The Program.
  - drfuchs 4y ago
    Make sure to check out the dedication!

ThomasBHickey 4y ago

Back in the day I worked quite a bit with Knuth's early SAIL (an extended Algol on the PDP-10) implementation of Metafont. They could have used some of the documentation the later WEB versions had as he tended to get tricky with squeezing everything out of the 36-bit words (which I was porting to a 32-bit word machine). But the code was an education and a joy to read well before he polished it for publication.

dhosek 4y ago
I’ve heard some wild things about the old SAIL stuff. I never had the chance to encounter it though. I got on the TeX train in 1985¹ with TeX82/MF84. AMS/TUG still were using the am* fonts for their publications. ⸻ 1. My very first exposure was DEK’s article “TeX and Metafont” in a copy of Dr Dobb’s Journal that was part of a trove my brothers got a hold of—and then in 1984 seeing someone in the IIT computer lab paging through a copy of The TeXbook, so when I found out that UIC had just installed TeX on their mainframe, I was one of the first people to use it there.

beardog 4y ago

I've been writing a literate multi-file program in Go and Copilot has been partially compensating for the lack of tooling support, especially since Copilot can infer from prose. I intend to make a post about my experience.

fzil 4y ago

> although sadly, literate programming seems all but dead now It seems alive and well in the data-science community to me. Look at jupyter notebooks if you aren't aware of what I am talking about.

nesarkvechnep 4y ago
It’s not really literate programming. It’s just editable/executable code intertwined with text. There’s no tangle and weave, or code reuse.
- tlarkworthy 4y ago
  What about this https://observablehq.com/@tomlarkworthy/redis-backend-1 https://observablehq.com/@tomlarkworthy/redis-backend-1
  - nesarkvechnep 4y ago
    The same thing. I don’t see chunk reuse, nor the ability to generate standalone documentation or export the code to files. Have you seen actual literate programming documents? The Noweb tool’s page has examples.
    - aljungberg 4y ago
      Sounds like nbdev which indeed exports code and documentation from a single notebook, plus unit tests for external execution.
    - tlarkworthy 4y ago
      The imports are chunk reuse. Each notebook is an es6 module you can import from any npm package.json You don't need to export it as documentation, it is executable documentation which is better, though you can print it if you want. The footer backs up the source to github Your stuck on Knuth's definition of literate programming but this is better than that
mellavora 4y ago

froh 4y ago

I think LSP language server protocol and literate programming are a match made in heaven. A simple syntax like noweb and a LSP dispatcher which only handles the noweb syntax elements and dispatches both text and code chunks to respective back ends; the LP LSP Server tangles the code chunks and presents the tangled code to the code specific LSP servers and does the mapping forth and back of the position-in-nw vs position-in-$code while passing all other communication through. especially now that we have DAP something like this would really make sense, wouldn't it?

junon 4y ago
Speaking anecdotally, I have nothing but issues with LSP. It's a pain to use, a pain to configure, gives sub-par results and is usually wraps with extra "features" that change how code gets edited between different languages (I know this is less LSP's fault). Not to dismiss the mountain of work people have put into it, but it feels very hacked together and clunky rather than a shining achievement.
- tuukkah 4y ago
  Case in point, Microsoft develops an editor (VSCode) and LSP so that N*M language integrations wouldn't be necessary. But in the development of their language (TypeScript), LSP support is not a priority (in part because LSP is inadequate in its current form): https://github.com/microsoft/TypeScript/issues/39459 https://github.com/microsoft/TypeScript/issues/39459
  - codethief 4y ago
    > We're working on this, albeit slowly. tsserver's implementation predates LSP so it's nontrivial work to move forward in a way that doesn't adversely affect old clients or result in code duplication.
    - tuukkah 4y ago
      Good to hear you're still committed. By "not a priority" I mean we have been waiting since this was published back in 2016: "[LSP] also means any developer can have a consistent editing experience for their favorite programming language on any tool – even if that tool isn’t VS Code." https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol https://code.visualstudio.com/blogs/2016/06/27/common-langua... The original bug against Typescript was opened in 2016 as well: https://github.com/microsoft/TypeScript/issues/11274 https://github.com/microsoft/TypeScript/issues/11274

kzrdude 4y ago

With the sorry state of latex engine error messages and the version number still approximating pi, e, something, it is no longer an ideal to me. It represents stagnation. Being bug-free may be good, but at some point feature development is needed. (I know TeX and LaTeX are not the same)

dhosek 4y ago
There are some serious legacy issues with the LaTeX ecosystem. The lack of being able to version individual package dependencies for a document is a huge one. You’re at the mercy of lots of independent packages which often have complex webs of interdependency. Probably the biggest mistake was the choice to abandon the idea of having a LaTeX 3 version with its implicit breaking of backwards compatibility. Backwards compatibility means that there’s a tangle of fragility that only grows with time which is part of why the error messages are so frequently bad. Changes are a fraught proposition. This is part of what inspired my decision to start work on finl.
- kzrdude 4y ago
  Best of luck

TanjB 4y ago

TeX was beautiful. Both the algorithms (it was a masterwork on typesetting, still a good reference for anyone doing text layout) and the book.