[HN Gopher] Code 'meaning-making' helps creating more nuanced so...
       ___________________________________________________________________
        
       Code 'meaning-making' helps creating more nuanced software
        
       Author : ricvolpe
       Score  : 40 points
       Date   : 2021-06-12 09:30 UTC (1 days ago)
        
 (HTM) web link (psytechread.substack.com)
 (TXT) w3m dump (psytechread.substack.com)
        
       | thom wrote:
       | Been thinking about this stuff a lot recently, partly driven by a
       | couple of threads here about 'good commit messages' and things
       | like that. We end up with a lot of context and intention outside
       | our code, which I personally think is a massive failing.
       | 
       | In my OO days most codebases lacked a layer describing what the
       | actual use cases of the system were. You'd maybe have a bunch of
       | 'controllers' in a web app, or a service layer through which
       | everything funnelled, but they were quite light in terms of
       | meaning. In functional programming we talk a lot about pipelines
       | of transformations over data, instead of the chain of policies
       | through which some business information passes. Obviously some
       | people write more or less intention revealing code (and not
       | everybody works in a sort of enterprise environment where this
       | stuff is paramount), but it's rarely taught as the entry point of
       | an architecture. The closest is probably just functional tests,
       | which most people appear to hate, and are rarely first class
       | citizens in your codebase.
       | 
       | I've been wondering lately if there is some space in programming
       | language design to address these issues. One (impractical and not
       | entirely original) thought experiment I've found interesting is
       | this: what if your codebase was entirely append only? What
       | primitives would you want to be working with? You'd probably need
       | more hooks, more late binding, more policy objects, to be able to
       | change processes over time. But out of that you'd get some
       | interesting properties, like a much more structured history of
       | your understanding of each business process, much better than a
       | textual changelog. There was a brief period where DSLs were
       | fashionable but I'm not sure that's the solution, certainly it
       | doesn't seem a popular approach these days.
       | 
       | Anyway, I found the article interesting. In software there are
       | always two models at work: the model we're implementing in code,
       | and a meta-model in the wider world that causes us to change the
       | implemented model. I wonder if there's mileage in being able to
       | represent _both_ to some extent in the artefacts we build.
        
         | rpvnwnkl wrote:
         | Are you thinking of something like Literate Programming?
         | [https://en.wikipedia.org/wiki/Literate_programming]
        
           | thom wrote:
           | I think literate programming moves _some_ context _closer_ to
           | the code. Sadly I think the modern version of this is the
           | notebook, and these are not things that are built to last.
           | But really I'm picturing working on codebases where lots and
           | lots of freeform text, either in the same file or elsewhere,
           | isn't necessary, because the language or framework guides you
           | to express everything all at once. It's a fuzzy picture, I'll
           | grant you.
        
         | pbourke wrote:
         | > most codebases lacked a layer describing what the actual use
         | cases of the system were
         | 
         | > I've been wondering lately if there is some space in
         | programming language design to address these issues.
         | 
         | I think we often over-index on programming language features to
         | solve these issues. A picture is worth a thousand words and a
         | few good words are worth a thousand lines of code. Most
         | internal systems lack even rudimentary documentation that
         | describes the architecture, operation and use cases for it.
         | 
         | Systems in which the designers take the time to write down the
         | way that things are in terms that somehow tie back to the
         | software (function names, class names, etc) would be a vast
         | improvement. The wiki is still an ideal document for this kind
         | of thing - you can link directly to the code from text that
         | discusses it. It's very helpful to be able to embed diagrams
         | alongside the text as well using a simple graphviz/mermaid
         | style notation.
        
       ___________________________________________________________________
       (page generated 2021-06-13 23:02 UTC)