[HN Gopher] Noweb - A Simple, Extensible Tool for Literate Progr...
       ___________________________________________________________________
        
       Noweb - A Simple, Extensible Tool for Literate Programming
        
       Author : Tomte
       Score  : 54 points
       Date   : 2021-02-27 20:11 UTC (2 hours ago)
        
 (HTM) web link (www.cs.tufts.edu)
 (TXT) w3m dump (www.cs.tufts.edu)
        
       | iluvblender wrote:
       | I have been using http://leoeditor.com/ for couple of years and
       | it is an essential tool in my workflow. Great to see other
       | literate programming tools out there.
        
       | mmcdermott wrote:
       | Literate Programming is one of those ideas I keep coming to.
       | There is an idea there that touches on something I find to be
       | true about software development, namely that the communication of
       | an idea to other humans is the most critical piece. There is a
       | similar idea in Naur's paper "Programming as Theory Building."
       | 
       | That said, I've never loved the LaTeX-centric nature of most
       | tools. I don't like heavier markup systems while I am writing
       | prose, which is why I wrote SpiralWeb
       | (https://github.com/michaeljmcd/spiralweb) as a Pandoc/Markdown
       | centric tool.
        
         | loa_in_ wrote:
         | I found Mr. Ross' funnelweb utility to have the best syntax.
         | Unique and easy to read.
         | 
         | http://ross.net/funnelweb/tutorial/index.html
         | 
         | Unfortunately the only known implementation was last updated
         | over two decades ago, and is written in pretty hard to
         | understand C.
         | 
         | I asked for permission and started a repository here:
         | https://github.com/loa-in-/fw-utf8
         | 
         | I currently have it unmodified there, except for disabled check
         | for ASCII range. (this modification is included in initial
         | commit, sorry, my bad). Otherwise code is the same.
        
         | sidpatil wrote:
         | Obligatory shilling of Org-babel, for those using Emacs and
         | Org-mode: https://orgmode.org/worg/org-contrib/babel/
        
       | fjfaase wrote:
       | I am working on a tool, which can take a collection of MarkDown
       | files with fragments of C code, and can combine these into a
       | single C file, where all fragments are placed in an order, such
       | that they can be compiled. Because defines can change the meaning
       | of code depending where you place them, there are some
       | restrictions on the input files. An example of the type of input
       | file I have in mind, is given at
       | https://github.com/FransFaase/RawParser/blob/master/docs/gra... .
       | The tool I am developing, and which is far from finished, can be
       | found in https://github.com/FransFaase/IParse in the
       | MarkDownC.cpp file.
        
         | qbasic_forever wrote:
         | Check out lit.sh, it's a super simple shell script that does
         | what you're after: https://github.com/vijithassar/lit It's
         | basically a one way markdown to commented source converter. One
         | really slick thing is that since it just comments out the
         | markdown you lose no information about line numbers and can
         | interpret errors from your compiler, etc. with ease (something
         | which is almost impossible with more complex literate
         | programming systems like noweb).
        
       | gnuvince wrote:
       | Hijacking this topic to talk about something I've been thinking
       | about lately: literate diffs.
       | 
       | I find that the order of diffs given by git is not optimized for
       | helping a reviewer understand the change. Sometimes the order of
       | files will not be in the most logical way; sometimes unrelated
       | changes (e.g., a text editor removing blanks at the end of lines)
       | create noise; etc.
       | 
       | I've been thinking that it would be interesting to have a tool
       | where the author can take the diff of their commit(s), order them
       | in a way that is conducive to understanding and explain each part
       | of the diff. That'd be similar to having the author do a code
       | walkthrough, but at the pace of the reader rather than the
       | author.
        
         | jonahbenton wrote:
         | Take a look at the term "Semantic Source Diff", eg
         | 
         | https://martinfowler.com/bliki/SemanticDiff.html
         | 
         | Tools in this space date back to the 1990s. There is a recent
         | upsurge of interest, a number of capable tools for different
         | languages are currently available.
        
           | briv wrote:
           | Pijul gives me hope semantic diffs may become common - see
           | the "Dependencies" paragraph of
           | https://pijul.org/posts/2020-11-07-towards-1.0/. The HN
           | comments on that -
           | https://news.ycombinator.com/item?id=25032956 - are a nice
           | read as well.
        
         | mikepurvis wrote:
         | Love it. Currently there's a gap where the diff is generated by
         | your review platform, but it would be amazing if there was a
         | way to submit your annotated/ordered diff and the platform
         | would use it as the review starting point, provided it passed
         | validation in terms of actually being a representative and
         | equivalent diff.
        
         | memco wrote:
         | What you're describing is already possible with Git: rebase and
         | committing chunk/lines allows you to organize your changes
         | coherently. The trick is finding ways to get into the habit of
         | doing it that way and staying consistent with the whole team.
        
       | zimpenfish wrote:
       | Not only is the link to my cross references in TeX broken, I've
       | no idea where that code currently is either. Although given the
       | lack of complaining emails about it, I doubt many people are
       | using noweb these days, much less with plain TeX.
        
       ___________________________________________________________________
       (page generated 2021-02-27 23:00 UTC)