Hacker News Reader

> I wish there was some reasonable standard (like a better version of Rich Text) that was commonly adopted so other languages could put graphical pictures in the source code.

I have felt exactly the same for many years. It would need to be something that was totally open (to achieve wide adoption), and reasonably easy to support in IDE's for edit and preview. And git-friendly. Belly-flopping on an existing standard is probably the easiest way to make that happen.

One thought is to presume a block comment with a language-specific marker, and make the contents a restricted subset of Postscript. a) You get one or two open-source fonts. Deal with it. b) The rendering area is strictly limited, c) the operator subset is limited to something reasonable -- like just enough to do a monochrome version of 80% of the kind of graphics that PowerPoint-ish programs give you.

Of course, you would never want to write Postscript by hand (although it isn't hard) but an IDE should be able to support a graphical editor plug-in. Or in a pinch you could even use another tool that left the rest of the code alone, and just edited the graphical block comments.

How about 3 fonts (serif, sans, and fixed) and color instead of monochrome? You're too quick to compromise :-)

Vector graphics would be adequate and could discourage huge binary dumps in the code, but you know someone would try to jam a photograph in there by inserting a square per pixel, and I can't really blame them. Postscript could work, but if you picked something explicitly line oriented it would cause less confusion in revision control.

> How about 3 fonts (serif, sans, and fixed) and color instead of monochrome? You're too quick to compromise :-)

Minimal Viable Picture :)

> Postscript could work, but if you picked something explicitly line oriented it would cause less confusion in revision control.

Agreed. But Postscript has a lot of existing unencumbered infrastructure code littering the net. With a new syntax, you need to overcome an activation energy problem. You would have to make sure that rendering and editing code existed that could be munged into a plug-in for everybody's favorite IDE. EMACS mode, anyone?

Also, maybe an independent tool that ran in a local web browser (not uploading code to random servers) would be a way to jump start things.

SVG could work (if you can stomach XML). The great thing about standards is there are so many to choose from.

or base-64

There's a Visual Studio plugin that I use that does this. I have an images directory in my source tree and in comments I can refer to them with syntax that looks something like:

/* <img source="images/bubble_sort.png"/> */

If you have the plugin installed, the image is displayed immediately after that line.

You mean like the 'pic' language? http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-20.h...

Developed in 1982. Present on almost every UNIX-like system and integrated into the manpage generator.

Probably the main reason we've not seen things like this achieve wide adoption is the small but very influential subset of programmers who refuse to use anything that isn't a pure text terminal for development.

Interesting. I'm not familiar with "pic", but I'll check it out. I've never seen a manpage with that in it.

A terminal with graphics in it would be nice too. Maybe if Tek4014 (and the Tek emulation in xterm) had graphics and useful text simultaneously it would've been more popular than the modal approach. I've also heard of Sixel, but never seen it live.

This isn't that hard to keep in an editable form for you. Visualizing it as an image can just be a property of the editor, and the "on disk" representation can simply be a URI to a standard image format. This is basically what emacs org-mode does, and it works really well.

I should check out org-mode. It's been more than 25 years since I used emacs with any regularity.

For Visual Studio, the Supercharger extension is capable of embedding images in comments. Those with Supercharger will see the inlined image, and those without will just see the markup containing the image path. It's not as powerful as what Racket is capable of with images-in-code, but gets the job done for most purposes.

Since Markdown is now the web's rich text, its image tag is probably the thing to try. Then, Emacs is guaranteed to be able to show images. Possibly Intellij Idea, since their MPS supports wacky stuff in DSLs' editing interfaces. Dunno about Sublime etc., but I hope Atom and company can make proper use of their platform. Even if not inline, an image can often be opened in a split frame.

BTW, Mermaid and such might be more suitable for embedding diagrams in comments―maybe even just one of the ascii art diagram languages (for which there are utils to convert to graphics).

If you dive into old Lisp Machines and Interlisp-D papers, it was already a feature back them.

Many FOSS devs don't have a full picture of Lisps, by constraining themselves to what Emacs+SLIME are able to, without experimenting commercial Common Lisp environments.

Thanks for pointing out the image part. I also do this with both Python and Mathematica all the time just like you, but haven't touched Racket in 10 years.

> Obviously there are downsides to putting images in your source. After you do that, your code is no longer ascii, and it won't be something you can edit with vi, emacs, or any non-Racket IDE.

Emacs handles images.

Mathematica allows similar things to be done in its notebooks. Fun!

> Just being able to put an image in a comment explaining your algorithm into your code would be huge improvement

i do this all the time.

Comment Area Markup Method Literary Programming, Programming was the first, Literary was the second.

the main purpose of the Code comment area markup method is to live Preview directly in the Code Editor Preview panel without exporting or any preprocessing.

Just add a line comment character of the programming language before each line of Markdown.

In the comments of code, you can draw flowcharts, tasklist, display data visualizations, etc.

The method is to add extension instructions in any programming language comment area:

markdown manual eval code, live eval code, print result, display data visualization and other directives When previewing or converting a format, you only need to simply preprocess: delete line comment characters with regular expressions, example: sed 's/^;//' x.clj

Note:

line comment character of Clojure(Lisp) is ; line comment characters of the current file type can be obtained from the editor's API. when we edit the code, we can preview the effect in real time. Editing literary code has a live preview panel like most markdown editors.

[Markdown Literary programming that don't break the syntax of any programming language](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)