Hacker News Reader

Comment by eterps | Hacker News Reader

What has always suprised me about open source software is that the source is always 'out of band'. I can imagine a future where all open source software you use has an 'edit source' function (as opposed to a mere view-source function we have on the web currently).

Even more useful would be the ability to make a change within a certain context, similar to how 'inspect element' works in the browser.

A change in the source would result in a patch which can then stay 'personal' or be automatically shared with others looking for similar functionality, or getting noticed by the maintainers who might incorporate it in the main releases after a refactoring.

Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future.

View on HN

That's how Smalltalk worked in the 70s (or Squeak for a modern dialect). You can edit any part of the running system and it takes effect right away. One classic example is redefining "true" to "false" and watching the system grind to a halt. Genera was similar for LISP machines in the 80s, you had full access to the code and could modify it on the fly.

Ironically one reason that always comes up when people here talk about why Smalltalk never took off is that it's hard to integrate with source code control systems like git that are file-based.

That's exactly how emacs works actually[1]. Getting the documentation on a function or variable contains a link to the file that defines it, which you can then edit. If you eval the expression then all later uses of the function will have the new behavior, otherwise it'll take effect on next startup. I've done exactly this to backport some changes from future versions.

[1] http://prntscr.com/u6yfnp

Yes, I really like how easy it is to view the definition (which might be written in Emacs Lisp or C) of any function callable from Emacs Lisp.

(But I never edit any Emacs Lisp files that come with Emacs: sometimes though I will make sure such a file has been loaded, then override a function definition with one I wrote myself.)

Yeah, overriding (or advising[1]) the function in init.el is probably the better thing to do if it's a long-term behavior change. In this case I knew that it would be right once I upgraded, so the dirty hack won the day haha.

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...

> What has always suprised me about open source software is that the source is always 'out of band'

From "Open Source is not enough" by Adam Spitz[1]:

The Open Source movement is great, but it doesn’t go far enough. […] When I feel the Urge To Tinker, only rarely does it feel like a loud voice shouting in my brain with enough energy to propel me to find the website and download the source code and figure out how to find the part of the code that corresponds to the thing I’m looking at on the screen and make the change and restart the program and retrace my steps. Much more often it’s just a quiet voice mumbling, “Hey, it’d be kinda neat if…” and then I think, “Well, it’s Open Source, I guess I could go download the source code… but… meh, it’s so far out of my way, not worth it,” and the urge fizzles out. I think that a lot of potential human creativity is being wasted this way.

> Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future

I've been thinking a lot about this and working on it. On a technical level it's more possible than it seems—even with "conventional" toolchains—but the primary obstacle is going to be social rather than technical. Funnily enough, GitHub's popularity and its measurably less-than-optimal workflows actually serve as a preview of how difficult it will be overcoming stalwartism from people who are technophiles first and only think of productivity as an nth-level concern—somewhere at a lower priority than social media presence and ginning up demand for the skills and practices they've alrealy invested in.

1. https://web.archive.org/web/20151016184630/http://adamspitz....

Thank you! My thoughts exactly. I just reposted this article:

https://news.ycombinator.com/item?id=24295133

Can you share some of your thoughts how this might be technically possible even with conventional toolchains?

I've written about it before, but nothing I've worked on is in a good state that I can point to as an example. A big part of turning the tide is going to be about getting the messaging right, because even with the ability to grandfather in conventional toolchains, it requires a perspective shift/attitude adjustment on the part of developers, and oh boy are developers going to revel in shitting on the idea and downplaying the costs of continuing to do things the same way we always have. It involves non-destructive compilation and the ability to (re)publish tooling for a common platform.

I've seen multiple comments here on HN in threads about compiler development where chrisseaton points out that compilers are pure functions. All you really need to do is combine that observation with the observation that we already have a near-universal substrate for doing computation. (And it might help further to recognize that releasing an open source project is fundamentally an act of publication, almost-but-not-quite in the vein of Knuth's literate programming.)

There used to be an assembler called RosAsm in the early 00s, whose author insisted on including the full source of the assembler inside the PE executable. That way you could edit RosAsm's source (written in the same assembler dialect) and assemble it by itself and produce a new PE executable.

Reply on news.ycombinator.com