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 - ▶ this video Jack Rusher - Stop Writing Dead Programs - link

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) ▶ this video and so on. The statement is simple: for COMMERCIAL REASONS we tried to subdivide and isolate software to sell it in pieces, oh, for decades people have SUFFERED without knowing the existence of alternatives such crappy model, a step at a time, with decades of time in between old features are reintroduced selling them as news while they aren't, and only when someone have found a way to made them anti-user. Your project actually use one of such step, the modern web, witch is a limited and limiting anti-user version of classic DocUIs, since the user have essentially no practical control of them, at least not a comfy one, and rediscover the power of integration, but limited due to the limitation of today tools. Not made do mix data and code, not made for end-users programming and so on. I've no doubt it can succeed simply because it's a piece of an ancient tech we need, but the point remain: modern software is untenable and it block an enormous slice of potential innovation and computing power just to enslave users.

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 compare it to Project Mage in any meaningful way, except it's also a live environment. [1] link [2] link [3] ▶ this video