Shell Literate programming first steps

I'm trying to understand literate programming as it ought to make life much easier, but only after climbing the steep learning cliff of emacs and org mode, but what is life without a challenge? ;)

I've only just come across some shortcuts to make life slightly easier, so I'll post them here for reference. At least so I know where to find them. I don't know what they are officially called.

This is an AI generated list:-

TAB expands to
<s#+begin_src ... #+end_src
<e#+begin_example ... #+end_example
<q#+begin_quote ... #+end_quote
<v#+begin_verse ... #+end_verse
<c#+begin_center ... #+end_center
<l#+begin_export latex ... #+end_export
<h#+begin_export html ... #+end_export
<a#+begin_export ascii ... #+end_export


On my system '<c' creates #+begin_comment. So much for AI!



 
Your question is about emacs isn't it? That has nothing to do with literate programming other than being a useful tool.
Maybe so, but almost every example of its usage seems to use emacs.

I found this which uses something called noweb but from what I can make out emacs org mode provides a superset of this program.
 
Right, so this is what you are using https://en.wikipedia.org/wiki/Noweb

There's a nice LJ paper here giving an introduction to how to use noweb https://www.linuxjournal.com/article/2188
I would start there, then read up on emacs org mode.

It's basically a kind of macro language that takes a single source file and generate both program code and documentation from the same source. The original literate programming idea came from Don Knuth, I think. There are a number of different literate programming systems out there. It can be very effective, but it's a steep learning curve, and it's usually pretty abstract. Maths guys love it.
 
Hey Balanga, which literate programming system are you using?
I'm just trying to pick up the basics to help me with lots of 'undocumented' shell scripts strewn across multiple directories.

When I come to look at what they do I can't figure it out even though it took ages to write and test.
 
I'm just trying to pick up the basics to help me with lots of 'undocumented' shell scripts strewn across multiple directories.
I'm not sure literate programming is going to help you with that. It's supposedly useful in writing programs, not organizing multiple programs.
When I looked into it, years ago, it was a lot of work to get started with a need to learn how to integrate other things, like LaTex. I spent too much time trying to figure it out.
 
What's the goal? I think most developers in all languages initially design their project from a practical point of view. The literate part is graph paper to me.
But Emacs? No thanks, the entire computer was already the workspace. We're not going to work in a closet.

I wonder what's supposed to happen atm you find out you need a conditional loop to get something done. Explain in human language...
 
Literate programming has been kicking around for a few decades, since Knuth's original paper. It really comes out of academia. There are a number of different literate systems out there, they all seem to be tied to particular academics in different universities. It lends itself to the creation of highly abstract systems like protocol stacks, but the problems come when you try to maintain the code that it generates; after tracking down the bugs in the generated code, you have to go back into the literate system and figure out how to change the macro language source so that it generates the correct target language code to fix the bug; or even worse, you embed some working code into the literate source, and end up with a hodge-podge of literate source code with bits of C code (or whatever the target language is) embedded within it. I don't think it has found widespread success, but it has been adopted in some niche areas; things like network protocol stacks and cluster managers, having complex sets of large numbers of nested state machines, come to mind; done properly, it can be efficient and effective, in the right context. One of the purported advantages is that both the target code and the documentation are generated from the same macro language source, so theoretically it's easier to keep both in sync; when you make a change to the code generation macros, you also change the documentation text that sits right beside it in the macro source, so when you run the generation phase you end up with a pile of compilable program source code and a bunch of documentation files that are all in sync. That's the hope, anyway. :)

Of course it also tends to make your code completely inscrutable to most other people, so it benefits your job security, provided the place you're working at keeps using it. But as usual that can also be a bit of an 'own goal', because you end up becoming an expert in the literate system, and nothing else. 😂
 
What's the goal? I think most developers in all languages initially design their project from a practical point of view. The literate part is graph paper to me.
But Emacs? No thanks,

I think emacs should be taught in kindergarten so that people can appreciate how many options it provides to a computer user over a lifetime.

It isn't something you can pick up in five minutes
 
I think emacs should be taught in kindergarten so that people can appreciate how many options it provides to a computer user over a lifetime.

It isn't something you can pick up in five minutes
I think it contradicts the idea of a user interface and wants to do everything in its own castle because it's obviously efficient and interesting but not really. There are also a lot of linux distributions like this. 😆
 
blackbird9 Then that's a problem and they will struggle through life.
I think it's becoming quite a serious problem. There's been plenty of discussion at government level here recently, on banning smartphones for under-16's. Supposedly kids find them as addictive as hell and end up being barely able to read and write. I think the Aussie's have already banned them for schoolkids, in some way or other.

An interesting anecdote. We had one of the division exec's come over here from the US to give us a pep talk, a few years back. You know the kind of thing, "you're not making the dates!", and then a bit later "you've all done very well!". Anyway, somewhere near the start of his spiel, he actually mentioned that he himself, along with Gates, Ellison, Suckerberg, Dell... in other words, a bunch of his mates (or more likely, the guys he would like to be mates with), NEVER allow any of their kids to go anywhere near the things, or PC's, either. I remember him saying, "they know what they're doing". Which I thought was Quite Interesting; it stuck in my mind. Probably the only thing I remember, from that talk. I don't know how true it is, of course.
 
Back
Top