I think one of the most amazing parts of Racket, and one of the reasons someone should try it out if they haven't, is that the source code and evaluator support images and not just text. The following link shows one aspect of this:
Just being able to put an image in a comment explaining your algorithm into your code would be huge improvement over the traditional syntax colored ascii you get with most languages and editors. There are many times I've written an algorithm which is difficult to understand without the associated diagram I drew on the whiteboard or in an image editor. Racket lets you insert that image or photo directly into your source, and I think this is a significant improvement over putting a link to that image in a comment.
Racket also goes a step beyond that by letting images be values which can be assigned to variables or returned from functions. The link above shows this clearly. I'm sure there is some value in this as a teaching aid, and I think that's why they did it, but you can also return mathematical plots from your functions and so on. This feature is similar to the various interactive notebooks people use for Mathematica or Python, so it's not really specific to Racket, but it is interesting to play with.
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. Also I doubt it will play nicely with git any time soon. However, it's a neat feature of Racket whereas many of the other benefits in the article apply to any Scheme (Chez, Gambit, Chicken, Guile, etc...) or lisp.
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 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.
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.
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.
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.
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.
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.
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.
https://docs.racket-lang.org/quick/
Just being able to put an image in a comment explaining your algorithm into your code would be huge improvement over the traditional syntax colored ascii you get with most languages and editors. There are many times I've written an algorithm which is difficult to understand without the associated diagram I drew on the whiteboard or in an image editor. Racket lets you insert that image or photo directly into your source, and I think this is a significant improvement over putting a link to that image in a comment.
Racket also goes a step beyond that by letting images be values which can be assigned to variables or returned from functions. The link above shows this clearly. I'm sure there is some value in this as a teaching aid, and I think that's why they did it, but you can also return mathematical plots from your functions and so on. This feature is similar to the various interactive notebooks people use for Mathematica or Python, so it's not really specific to Racket, but it is interesting to play with.
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. Also I doubt it will play nicely with git any time soon. However, it's a neat feature of Racket whereas many of the other benefits in the article apply to any Scheme (Chez, Gambit, Chicken, Guile, etc...) or lisp.
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.