Comment by dhosek | Hacker News Reader

Comment by dhosek | Hacker News Reader

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.

> 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.

It’s not really literate programming. It’s just editable/executable code intertwined with text. There’s no tangle and weave, or code reuse.

What about this https://observablehq.com/@tomlarkworthy/redis-backend-1

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.

Sounds like nbdev which indeed exports code and documentation from a single notebook, plus unit tests for external execution.

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

You mean a system with heavy dependence on global state yet allowing for arbitrary command/code chunk execution order?

Where significant parts of the display remain out of sync with said global state?

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.

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.

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)

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.

Best of luck

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?

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.

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

> 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.

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-langua...

The original bug against Typescript was opened in 2016 as well: https://github.com/microsoft/TypeScript/issues/11274

Note I merely quoted from the above Github ticket. :)

I see. In that case, possibly replace "you" with "they" in my reply.

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.

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

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

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.)

You’re right! I had to go pull my copy off the shelf and check, but it really is TeX: The Program.

Make sure to check out the dedication!

Reply on news.ycombinator.com