Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I want a language that is designed alongside an editor/IDE. I want to stop putting comments in my code. I want it to be first-class for my code to be in the left pane and my comments to be in the right pane, always binded together with anchors but always separate so my comments don't have to adhere to the limitations of the code's text area.

And then I want to put rich things into my comments section like graphics and tables and such. And I don't want to have to write table-like Markdown or a shorthand that converts into graphics. I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.

Jupyter is pretty darn close to this. And I like it a lot. But I feel like I'm giving up a lot to make a notebook. I want this in a much more heavy lifting format.

View on HN

> WYSIWYG

WYSIWG is what you get, but not what you want. Anyone who has done serious work in Word, or some other WYSIWG editor has got to the point where the document becomes FUBAR, and you have to copy the plain text, and start again with a new document.

That is not acceptable for a programming environment. Copy an paste is the enemy of correctness.

>> WYSIWG is what you get, but not what you want.

Nothing stops you from allowing the user to access the document itself to clean up the automatically-created mess.

It should be more like the XML/visual editing modes of .Net platform UIs.

multiple projection modes.

'canonical view' is raw markdown/tex/whatever with text-editing controls. WYSIWYG view is presentation style with rich text editing controls.

this paradigm could carry over to the code itself with projections omitting/adding type annotations, comments, in-lined documentation, maybe even selectively expanding/eliding parts of the code itself i.e. orthogonal aspects like logging

> Anyone who has done serious work in Word, or some other WYSIWG editor has got to the point where the document becomes FUBAR, and you have to copy the plain text, and start again with a new document

I'm sorry but, speaking from experience, that is just not true in all cases. Granted, it takes a certain kind of methodic work (and more know-how of the tool than would be reasonable) to work around many of the problems but if you put in the time to learn, Word (and similar software) is more than adequate for large-scale editing work.

It's no wonder the absolute majority of people use it; the learn how to avoid the problems (or live with them) and there is near zero incentive to personally switch. The majority of the onus is paid by the next batch of people who have to learn it.

I'll also agree that it's not what I want for comments and that better models exist for 90% of all text-editing tasks out there. But it does work

What do you mean by "large-scale editing work"? Are you talking about the size of the document? The duration of the editing lifecycle? The number of participating authors and authoring systems? The full editing/consumption lifecycle for a long lived document that goes through many revisions and publications for several decades?

Things I've seen fail with Word in my career that would be unacceptable for programming:

- Relatively simple docs being eaten alive, as described in grandparent comment, after several dozen authors make small edits over the course of a few weeks.

- Complete change-tracking disasters when attempting to merge concurrent edits to different parts of a document by several authors.

- Docs where the WYSIWYG behavior completely changed when opened 5-10 years later by newer versions of Word. Attempting to import/export/save as to rescue it involves much of the same cut-paste and hand recovery described previously.

- Docs destroyed by international collaboration, where different locales of each editor seem to accumulate contradictions in the saved document over time.

- Inconsistent WYSIWYG between Word on Windows and Word on Mac OS.

I don't think it is responsible to promote a programming language that does not have a tooling-independent and platform-independent textual representation that carries ALL program semantics as manipulable, printable character sequences. That promotes disposable code and prevents real programming in the large.

(edited to try to rescue bullet list)

No, you don't want this. Every new generation of new programmers since the 1960's talks about this, but nobody to date has actually written any useful program using pictures and prose.

Sorry. Code is code, that's what your job entails and you can't make programming into something it isn't.

Code is code, but sometimes pages of code implement a simple mathematical equation or a process diagram. I would like to see it in addition to the code.

Add a plugin to your IDE, to display embedded graphics from comments.

Isn't this more an IDE problem than a language problem?

To be fair, Waterluvian was talking about including pictures and tables and such in comments, while still writing actual code. It's probably still a horrible idea, but for much more subtle (and less certain) reasons than "waaah, I don't want to have to do programming in order to make a program".

Would it be "a horrible idea" to include diagrams in code that implements a graph algorithm, or images in image-processing code?

Exactly this. Every sufficiently complex program that refers to graphs DO have those graphs. They are either in a separate document, or in the programmers head, or (poorly) added to the source code. There are plugins (e.g. for Visual Studio) that will render images refered to by file paths, in the editor. For complex graph-related stuff I imagine that can be pretty neat.

Python+sphinx allows to get that (and a lot more).

I would love to be able to include pictures and diagrams in comments. If it was in a text format like HTML or JSON it would source control nicely. The IDE could then display and allow editing them.

Slap a text editor into doxygen documentation and you'd basically have this.

People developing safety critical embedded systems using ANSYS’ SCADE Suite would disagree about nobody having written useful programs using pictures and prose.

I've heard this said about every new generation of programming techniques. It's true about every technique for which tooling isn't yet widely available, right up until somebody writes the necessary tools.

You could replace the subject of your comment with, say, "automatic garbage collection", and it would have been equally true ("that's just what your job entails!"), right up until GC made its way into the first mainstream languages, and it very quickly became a tool used by almost everybody.

GC is a much older technique than it looks, though: it's described in McCarthy's 1959 Lisp paper. https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/...

We spent about 3 decades arguing back and forth about performance until the wave of bytecode+GC languages took over and accepted those tradeoffs: Perl, Python, Java, Javascript.

Holdouts remain in the high performance, embedded, and deterministic areas of software.

Code as live objects is almost as old (Lisp, Smalltalk)

The point is that the idea of drawing diagrams instead of writing code (and/or integrating documentation text right into the source code) is a really old idea.

The idea is older than structured programming, older than the C programming language, older than the idea of object-orientation. It's probably even older than McCarthy's LISP.

Safe to say that if it hadn't caught on during this time, then it never will.

I want something like Rap Genius but in my editor.

This is not true. Sikuli was a super cool language, and it was fun to write with. I'm sorry it hasn't received more attention.

plenty of peopple are writing programs which get actual usage in visual languages - e.g. with max/msp, or the old SynthMaker, Kyma... as wells as some avionics software written in e.g. LUSTRE...

More recently, Unreal Engine's Blueprints too (and UE's Kismet before that). 3D modelling tools and texturing tools also often use visual languages for shaders, and, as you've mentioned, in audio its also relatively common. Lustre/SCADE is my favourite example though (and is used in a lot more than just avionics too, according to the ANSYS marketing material: transportation, energy, etc)

Unity definitely and effectively mixes pictures, audio and code, and has a large chunk of the mobile app market. It's automatic asset import is very good and fully customizable.

That isn't what he was saying, nor is what you are saying true. There isn't an intrinsic reason for code to be a text stream. There are environments that are in broad use where it is not, such as Simulink, LabView, and some of the big game engines today.

It's easy to be parochial about this when Unix like environments force everyone into a lowest common denominator of text streams, but don't take the limitations and bad ideas of Unix as laws of the universe.

Edit:

Summarizing the list of non-text mode programming languages in general use that people have mentioned in this thread:

ANSYS SCADE

Sikuli

Unity

LabView

Simulink

max/msp

SynthMaker

Kyme

LUSTRE

i guess i’m not a programmer copying all these pictures, diagrams, and comments with arrows anchored to the relevant code portions. (yes, i am able and do do this.)

In the 80s at FORTH, Inc. we had 'shadow blocks'. Forth code would go in one block and comments in the corresponding shadow block, and you'd flip back and forth with a keystroke. (We only had 80x25 text mode for coding, iirc. Your graphics would've been out of reach.)

I don't remember how or if people kept the shadow comments lined up with code (I was only there for one summer in high school), but you could extend the editor with ease, so...

> We only had 80x25 text mode for coding, iirc.

Traditionally a block was 64x16 I think (1KB).

Right -- I mean that was the only text mode the hardware supported, unless you had an EGA adapter which could squeeze in 80x43. Side-by-side blocks were right out.

This sounds like literate programming of some kind. A bit more advanced than Knuth's original WEB implementation, but certainly matching the idea that your code co-exists with discussion and diagram and so forth.

I used noweb at a previous employer, and it certainly was difficult to argue with the results; beautiful, readable documentation that existed as a first-class product, alongside the code it was describing. The quality of the software we generated was the highest I've ever seen in terms of things like deadlines and budgets and bugs and testing.

That's what it sounds like. So, it's pure text (and easy to version control), and you can compile it two ways: Once for the machine to execute, once for humans to read.

The code-to-IDE transformation described here could be trivial. Right-pane only shows comments, which are neatly folded away in the left-pane. Doesn't really scream "next level" to me but I'd definitely use it.

You could probably achieve this with an IDE that understands your rich text comments (maybe code them in JSON or base64 binary). To me it seems like a pure presentation problem.

This.It is already happening. For example, for annotations in some PHP frameworks. The annotations are created as comments in some specified format and then the framework uses reflection to read and parse those comments. Some IDEs can also parse those comments making it somewhat similar to what GP suggested although in a very primitive and simplified form

People forget ASCII is just a presentation mode. There's no reason for Ox41 to be an 'A'.

I want a language that is designed alongside an editor/IDE.

Why would this require a new language? And why would it require a new editor?

For one thing, at a certain scale, code and documentation are examined in a browser more often than in an editor.

Your requirements seem too focused on insignificant details and not enough on the big picture.

That's only because the browser is the lowest common denominator for rendering. We could all be using emacs if the rest of the planet was comfortable with lisp and orgmode.

Apostate. Vim is the one and only true editor we all need.

TempleOS can put graphics and formatted text into your source code, it does a lot of other neat things I wish modern computers did.

Any language should be if not developed by the tool developer, at least developed with tooling in mind.

Compiliation for an editor (partial/incremental) is a very different beast from "normal" compilation, and any compiler that is first completed for regular compilation and then tries to address tooling as an afterthought, will ultimately never be useful in tools.

I realize writing a new compiler is hard enough in itself, but projects like the Roslyn poject shows it's at least feasible to make a compiler-as-a-service with both regular compilation and tooling in mind.

> Any language should be if not developed by the tool developer, at least developed with tooling in mind.

I completely agree. A few things I think would help with this:

1) Provide a standard "machine readable" concrete syntax for the language, alongside any "human readable" syntax. S-expressions would work well for this; if someone prefers JSON or XML then I won't argue. The implementation (compiler or interpreter) should have a mode which converts the human syntax to the machine syntax. The compiler/interpreter should handle inputs in either format. This avoids tools having to parse human-readable formats (or worse, run arbitrary preprocessors, etc.), and makes it easier to feed auto-generated or modified code into the system (e.g. for type checking, etc.). Machine-readable formats are also be more robust, since everything's delimited in a standard way, so unknown things (e.g. new language constructs) won't mess up the parsing of everything else, making tooling easier (e.g. linting, documentation generators, etc.). Note that Lisps and Schemes have this already, by virtue of using a machine-readable language as their human-readable language. Others can maybe just serialise their parser's output (as long as it's concrete, not abstract).

2) Allow arbitrary metadata to be attached to pieces of the syntax tree (in both formats). This can be used for comments, but also for source location (e.g. if it's been translated from the human-readable format, or maybe even transpiled from something else). The parent's desire for graphics, etc. in comments could be handled by such annotations, since they're data not just ignored bytes, so they could have e.g. entire Scribble documents attached. Tooling can use this for any data they like, e.g. hints for static analysers, dependency information, required language version/features, blame information, optimisation hints, etc. I think Clojure already allows this, but I've not used Clojure.

3) Keep context/configuration close to the code, or at least allow it to be. For example, if the meaning of some code changes depending on language version, it should be possible to specify the language version as part of that code. That way, tooling is able to obtain and use that information. This could use the annotations from (2). The worst case is when crucial information (like language version, or which arbitrary program to run as a preprocessor, etc.) is kept in some external configuration file, in an arbitrary location, in some bespoke file format, such that no other tooling can make sense of the code (I'm looking at you Cabal!). Even if we want separate config files, the tools which handle them should be able to resolve and propagate that information into the code, e.g. we could ask `tool annotate src/foo.lang` to get a copy of `src/foo.lang` which any relevant context/metadata from the config file appended as a file header. IDEs can use this to get more info about the files they're editing, and propagate that info into the snippets they send into the implementation for type-checking, etc.

smalltalk, in particular pharo smalltalk, is doing exactly that. i don't think it supports including graphics in comments, but there is no reason that couldn't be changed.

to top it off, it had the potential for that already since its inception. so not exactly a new paradigm

I'm also becoming a fan of Pharo the more I use it. It just feels so good to use. My only complaint about it is that I really miss ctors with arguments.

I don't like init functions; an object should know from its inception the basic things it needs to in order to function, and I think it's a great miss there is no real way to force this.

i am not familiar with actors, but i'll read up on that. however your second point sounds kind of logical, so i wonder what the problem is here. can you give an example of how an init function is used to do something that an object should already know?

> actors

Sorry, I should've been clearer there. I meant constructors.

> can you give an example of how an init function is used to do something that an object should already know?

The only way to instantiate a new version of an object in Pharo is with the new message to the class, for example with

  aDate := Date new

However, that point does not yet know what its time offset from epoch is, which is absolutely vital when trying to use a date. It needs to be instantiated at construction with that information. How pharo gets around is by essentially creating class messages which hand you back the instantiated object, such as with

  aDate := Date year: 2015 month: 12 day: 31

However, this is just syntactic sugar (as far as I can tell, please someone correct me if I'm wrong) for a class message calling new and setting the properties on the object it just created. It is a fairly clean way to create objects, in general.

However, the method 'new' can still be used (there is no access modifiers in Pharo), so it's still possible to call an object without ensuring it's initialized properly. I have yet to find a good way around this.

oh, i get it, so there was actually only one point: constructors with arguments instead of init functions that wrap around new but don't disable it.

and yes i agree, it should be possible to prevent the creation of uninitialized objects.

> it's still possible to call an object without ensuring it's initialized properly. I have yet to find a good way around this.

Implement the class's new method with an implementation that just throws an UnsupportedOperation exception?

> I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.

There's a thing for everyone, but that dystopian stuff you are describing here I cannot fathom even in my worst nightmares. The text file is a very powerful abstraction for programming and I hope it will never day.

text is terrible for communicating high-level structure and data flow in programs, as well as asynchronous and parallel programming paradigms. it’s clear that if programming is a way of thinking as much as telling a computer what to do then it is well behind nearly every other field in terms of visualizing and seeing and touching the hidden processes.

I like this idea.

It could take literate programming [1] to the next level. Existing tools like docco [2] can output beautiful documentation [3] with comments set alongside code. The language/editor described above would allow us to input code in the same side-by-side format.

[1]: https://en.m.wikipedia.org/wiki/Literate_programming

[2]: https://github.com/jashkenas/docco

[3]: https://underscorejs.org/docs/underscore.html

Markdown Literary programming that doesn't break the syntax of any programming language.

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.

Advantages

fast, live, simple, no interference.

It don't break the syntax of any programming language, you can compile directly. comment area markup method can be applied to any programming language and any markup (including Org,rst, asciidoc, etc.), which is the greatest advantage.

you only need a single line code to delete line comment characters using regular expressions, then you can use any Markdown parse or converter.

Support any code editor that supports Markdwon Live preview, allowing the source code of any programming language to become rich text in real time. In the code's comment area, You can use the markdown to draw flowcharts, tables, task lists, and display images on the live preview panel, enhance the readability of your code.

If you extend the Markdwon tag, you can implement the eval code, print result, display data visualization and other instruction tags, to achieve live programming, live test.

When writing (reading or refactoring) code files, It can modify and live preview directly in the editor without exporting or any preprocessing.

Reliable. Maximum code accuracy is guaranteed, and markup language errors do not affect the code.

It hasn't interfere anyone to read the code. Markdown is simple, so if it doesn’t have syntax highlighting, it doesn’t have much effect on writing and reading. And having a gray comment area doesn’t affect reading code, especially for people who don’t understand the markup language. Strict distinction between markdown and code, and gray comment area can reduce the amount of information in the source code file, conducive to reading code.

https://github.com/linpengcheng/PurefunctionPipelineDataflow...

> I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.

This specific bit reminds me of the elegant UX implemented in Typora. [1]

[1]: https://typora.io/

> I want a language that is designed alongside an editor/IDE.

Check out Luna

https://www.luna-lang.org/

Nice ideas but you might be better off with a folding editor or IDE where you can hide very long comment blocks.

If you haven’t tried a literate programming language, you might like it. You basically write a document with figures, etc. it is, with bits of executable code.

BTW, most of my coding in my last job was in Jupiter notebooks (to use Cloud GPU compute). Really not too bad for short ML scripts when you can still put slow changing library code you write in separate files. That said, not a great environment. I prefer configuring ITerm2 or xterm so I can get matplotlib plots to appear inline in SSH sessions.

PLT Racket lets you use images and other rich objects in their editor, and provides a framework for rich editors which that editor is written in. So there are pieces there.

Block oriented Forths used to use "shadow blocks" for documentation. You had a block that was code, and a fixed offset to a corresponding block that was documentation, with a keybinding to switch between them.

Various tidbits of this have been done in Smalltalk (of course).

But if you have already invested in a world of tool chains that assume ASCII or Unicode text streams as source code representation, then it's hard to get out of it.

You can do that for example with Haiku, so the comments would be saved as extra attribute. Sadly you would lost it if you move the sources to non-extra-attrib friendy FS. On Haiku some editor already using this functionality to save the cursor position, window size and position, current selection, etc as attribute.

I've yet to see anybody that really bothers writing comments or documentation, and, more importantly, keeps it updated to match reality. This is only getting worse these days, where even major libraries and frameworks from Fortune 50 companies barely have autogen'd javadoc-style information available.

Racket isn't perfect but it's the best example I know of. In DrRacket you can have image literals.

CNC programming with CAM software is very heavily visually oriented. I don't usually touch a single line of g-code other than to occasionally check certain things.

Your comment also reminded me of Godot's editor and gdscript. It's fairly domain specific(though the editor is actually a godot game). Everything's designed to work with gdscript. The language and the editor are designed to work seamlessly together in much the way you describe.

Isn't this a good description of stuff like Pharo?

Yes. Everyone should check it out:

https://pharo.org/

They have a pretty friendly community too.

Particularly GToolkit which is built on top of Pharo.

The future of programming languages is and has always been to simply reinvent smalltalk.

Seriously, read the original "Design Principles Behind Smalltalk" [0] and it still sounds very fresh, even radical today.

[0] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

I don't think this is a good idea, and I don't think it will ever happen on a large scale, simply because programmers use different editors for valid reasons.

It's a dealbreaker if everybody working on the same project has to use the same editor.

Development practices that seem suboptimal for the individual are often optimal for teams. And teams develop all the major pieces of software we use.

Using the same editor is not implied though. Only a common format for "rich" comments that is supported by a sufficiently large subset of editors. This could be as simple as using the same markdown/HTML/whatever comments as before but with WYSIWYG support in the editors.

One example of a project that is sort-of heading that direction is Jupytext

https://github.com/mwouts/jupytext

I'm working on something similiar but way different. High-level REPL with a UI editor enabling you to rapidly develop over multiple levels of abstractions that end up doing token translations to existing or provided custom implementations. You'll basically define data, define flow and persepctives on data and that's it.

Is there anything in Mathematica/the Wolfram language that falls short of what you want?

The pricetag

Projectional editing?

https://en.wikipedia.org/wiki/Structure_editor

I've seen that demo from JetBrains MPS, looks good. Hopefully it gets wide usage.

Why not using git, as in every significant code section, which deserves a comment shall be commited and commented freely in the git commit message?

Then what you need is just a git blame(?) to visualize the current code section's comments.

Would this work?

That would require a commit to be localised to a block of code, and even atomic commits can be split across multiple files and modules.

Plus, you would end up in a conflict between recording history and recording the present. What happens if you replace a complex method call across a codebase? The comments should explain the call, but the commit message needs to record how the call changed, and why - which you probably don't care about when coding.

I really like the idea of having better options for commenting right by your code.

I do believe a lot of code would benefit from better built-in documentation, which it essentially is.

I Will think about this some more

> And then I want to put rich things into my comments section like graphics and tables and such.

Swift Playgrounds has rich comments, but they are still inlined with code.

For R programming, Rstudio has got a notebook-type but within IDE a format called `Rmarkdown` that's pretty popular in academia.

Why don't you just use Java + IntelliJ or one of their sister IDEs?

Reply on news.ycombinator.com