summaryrefslogblamecommitdiffstats
path: root/2021/talks/mold.md
blob: 7c5eb7070fb80e31e16cedb16047898605f2bb5c (plain) (tree)
1
2
3
4
5
6
7
8
9







                                                                                 
                                                                                 
 

                                                               




                                                                      


                                                                      


                                                                        
                                            












                                                                          
            
 

                 





                                                                    
                                                                     
















                                                                        
                                                                    








                                                                        
                                                                     

                                                                     
                                                                   

                                                                        
                                                                       


                                                                 
                                                                      


                                                                     
                   


    




                                                                                                                                                                                                                                                              
 



                                                                                      






                                                                                                                                                             
                                                          
 
                                                          
[[!meta title="Moldable Emacs, a step towards sustainable software"]]
[[!meta copyright="Copyright © 2021 Andrea"]]
[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Moldable Emacs, a step towards sustainable software
Andrea mailto:andrea-dev@hotmail.com - pronouns: he/him -- https://ag91.github.io

[[!inline pages="internal(2021/info/mold-schedule)" raw="yes"]]

We could learn about things better. Mountains of knowledge hide in
places we cannot access or use. The more we write down, the more it
takes to find and understand things we find useful.

Knowledge (web, software, books) keeps growing faster and faster! This
is not sustainable: we cannot keep up with it! What if we repeat the
error of somebody else, only because it would take too much reading to
know? What if that knowledge is in some code we work with everyday?

Moldable development is a paradigm shift that attempts to solve this
problem. In a gist, the tool you use should let you create special tools
to learn smartly from what you have already.

Since we use Emacs, let's make our great editor moldable!

This talk shows my progress in making Emacs closer to such a tool. We
are going to see how we can mold structured (and maybe even natural)
text to learn better, how we can inject notes in our projects and how
self documenting this tool is!

I aim to inspire you to find a quicker way to learn from our digital
world!

You can learn more about this at: <https://github.com/ag91/moldable-emacs>

# Discussion

IRC nick: `andrea

Pad:

-   Q1: How to find a balance between «generic» molds that do not
    provide specific enough info vs writing a new mold for every new
    query/question?
    -   A: You can write molds that are private for your special
        problem. I created molds for my work that I don't share: like
        find the stories I am working on and how long time I spent on
        tasks lately. Also, moldable-emacs is to make these tools easy
        to write, so you should free to throw away tools when you need
        them once only. If I believe a tool is a good start for many
        other tools, I put them among the core molds, else if I use them
        often I store them as contrib. If it is a one off, I throw it
        away.
-   Q2: How would you evaluate this workflow for package managemnt in
    large independent codebases. Can one integrate it with code sematic
    analyzers to make for a better work flow?
    -   A: moldable-emacs is about creating custom tools you can apply
        to your situation. I started experimenting with molding NPM json
        packages + security data from OWASP to view/display security
        issues in my packages to my colleagues in the past.
        moldable-emacs gives me the infrastructure to answer my question
        about security, and I now started asking myself about
        architecture coherence, so I have scaled up tree-sitter over
        projects to check that modules don't use packages from other
        modules. By that I mean that as long as your code semantic
        analyzers output data, you can mold that (context) data to tell
        your story (answer the question you have). Does this answer your
        question?
    -   You answered it very well. I am also a security auditor for
        multiple development teams. And I am incharge of code analysis
        in an understaffed security team. So your usecase example got my
        usecase spot on. 
    -   Cool! For now you can define insecure patterns using tree-sitter
        expressions (for example, I find a variable called "password"
        in the code set to a string. For the package.json I linked to
        OWASP API and looped through the packages using tree-sitter
        tokens. I didn't get there, but I wanted to see an Org Mode
        buffer with the list of the most vulnerable deps highlighted by
        color + how to solve them: so I could pass them to developers to
        resolve them (I am a dev, but sometimes others don't know about
        security risks).
    -   Often molds are to tell stories to others.
    -   This is probably the most important thing for my personal
        usecase. Thank you very much. Now it's my turn to learn it and
        use it well. 
    -   Please open issues or email me, and I will try to help if you
        like how it works :)
    -   I'll do so.

IRC:

- cool...so essentially you are developing a text based version of Glamorous Toolkit.
  - `andrea:  yup, but only because I don't have good imaging in Emacs yet (but with tui.el...)
- your talk helped a lot with that though. I'd been seeing posts from you for a little while, but now I "get it"
  - `andrea: yeah sorry, I am still building my vision: it may look I have been all over the place (image recognition, editing css, parse English lately), but the common thread is the easing of creation of micro tools that help me tell the stories I need
- I love your approach of mining other 'nuggets' from other contexts and bringing them to Emacs. I really look forward to looking in to your work and see if I can implement some of it. Thank you so much for your talk.

Links: 

-   Telling a story about code using buffer views   <https://moldabledevelopment.com/>

# Outline

-   5-10 minutes: quick demo of moldable-emacs
<!---   20 minutes: same as above but going more in depth for the vision of the package, how it fits with my code-compass talk of last year and some features
-   40 minutes: same as above and explanation of how you can extend the features available
-->

[[!inline pages="internal(2021/captions/mold)" raw="yes"]]

[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]]