Tudor Gîrba - Moldable development

I believe this to be an artifact of our current paradigm of software development, which is based purely around static "batch processing" where the software can't be molded easily. (I didn't want it to come off as a plug, so I didn't add it to my original message, but I'm working on something to solve that.) To get a better idea of what I think is the better approach, check out these talks: Tudor Gîrba - Moldable development - [VIDEO] Jack Rusher - Stop Writing Dead Programs - [LINK]

Where has this tool been my whole life? :P Thanks for the link, I didn't know that one. Yes, this [VIDEO] is the kind of programmable system I'm talking about, creating behavior on top of your stored content with methods specific to the particular collections of data already in your system, and ideally with minimal syntax for transferring data among the different tools.

Wrote a review on it on the website, copypasting : Glamorous Toolkit[1] promotes the idea of moldable development[2]. There's a talk on it: Tudor Gîrba - Moldable development.[3] The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook. The site on moldable development states its difference with literate programming: They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code). And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment. The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool. But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated. It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself. I can't say I can comp

Do not take it as a judgment of your work, it's instead a broad observation using your work as a catalyzer to state it: I have much more integration with a much older app, it's name is Emacs, in my case it feature: - a Windows Manager, module named EXWM - a very powerful noting tool, org-mode - integrate to the note module there is file attachments, calendar, tasks, ... - a mail module, notmuch in my case, fully usable inside the note tool, so I can link a single message, a thread or a search query in a note, something simple as notmuch-search:tag:unread that open all my unread messages. - of course being a fully user programmable environment a mere link can execute code, meaning I have a clickable link to transform a note into a slide (zpresent, my favorite, but a mere zoom might suffice in most cases), a link can open a mail compose buffer and so on - I have various nice file handling goodies like mass renaming, regex selection and so on. This since DECADES. Now ending the joke the statement: classic desktop model feature an OS witch is a complete user-programming environment, apps are just bits of code, listings part of the OS, meaning that if you have a CAS functionality you can solve an ODE inside an email you compose, annotating it while composing and made a slide out of it. Take a look at [LINK] for Emacs, a demo for Pharo (a modern Smalltalk, the oldest of such classic desktop systems from Xerox) [VIDEO] and so on. The statement is simple: for COMMERCIAL REASONS we tr