3 ms·

This actually makes sense. I’ve always found it much easier to read code in an editor directly and jump around to understand it. I see the appeal of literate pr

This actually makes sense. I’ve always found it much easier to read code in an editor directly and jump around to understand it. I see the appeal of literate programming. But it promises to be a debugging nightmare.

badsectoracula 8y ago
I don't think it is really any different than debugging anything else. Literate programming, as i understand it, is basically done with a preprocessor (or two) that takes your "literare program" and spits out a human readable document and a machine readable source code. You debug the latter which is still the code you typed with the document bits stripped out, so it should map 1:1 to your literate program code.
- gmueckl 8y ago
  I think what it comes down to is interactive tooling linking code and documentation. When coding and debugging, you want to see all the relevant code without any noise (e.g. superfluous documentation). You want to change it in that representation and these changes ideally get transferred back into the documentation automatically. You may want to reorder sections of code and documentation on the screen as required. And so on. Maybe it is time to finally say goodbye to source files and place everything in structured and annotated code databases instead? Code does not have to be text.
js8 8y ago
"I’ve always found it much easier to read code in an editor directly and jump around to understand it." That's Java approach and it seems to be complete opposite of literate programming. Code that cannot be read or understood without having an editor and navigation. I personally like to read programs in full, although only rarely there is time to do that. Not exactly literate style, but I like when the documentation is structured hierarchically so I can focus my understanding where I need it. It seems that hierarchical problem decomposition, and the associated programming style (which leads somewhat naturally to literate programming), is out of fashion right now. (It was replaced by mesh of objects, frameworks and microservices.) Maybe it will return back with functional programming. Anyway, to answer authors question - I enjoyed Jones Forth.

badsectoracula 8y ago

I don't think it is really any different than debugging anything else. Literate programming, as i understand it, is basically done with a preprocessor (or two) that takes your "literare program" and spits out a human readable document and a machine readable source code. You debug the latter which is still the code you typed with the document bits stripped out, so it should map 1:1 to your literate program code.

gmueckl 8y ago
I think what it comes down to is interactive tooling linking code and documentation. When coding and debugging, you want to see all the relevant code without any noise (e.g. superfluous documentation). You want to change it in that representation and these changes ideally get transferred back into the documentation automatically. You may want to reorder sections of code and documentation on the screen as required. And so on. Maybe it is time to finally say goodbye to source files and place everything in structured and annotated code databases instead? Code does not have to be text.

js8 8y ago

"I’ve always found it much easier to read code in an editor directly and jump around to understand it." That's Java approach and it seems to be complete opposite of literate programming. Code that cannot be read or understood without having an editor and navigation. I personally like to read programs in full, although only rarely there is time to do that. Not exactly literate style, but I like when the documentation is structured hierarchically so I can focus my understanding where I need it. It seems that hierarchical problem decomposition, and the associated programming style (which leads somewhat naturally to literate programming), is out of fashion right now. (It was replaced by mesh of objects, frameworks and microservices.) Maybe it will return back with functional programming. Anyway, to answer authors question - I enjoyed Jones Forth.