3 ms·

The model of a program as a linear file of 80-column text is a historical accident based on IBM mainframes in the 1950s, and the decks of punch cards they read.

by kens 7y ago

The model of a program as a linear file of 80-column text is a historical accident based on IBM mainframes in the 1950s, and the decks of punch cards they read. It seems like there must be a way to treat text in a more flexible way without going to a full visual programming language. For example, consider all the things that have a physical order and position in a file that is actually irrelevant. Why can't methods (for instance) get displayed as convenient, without worrying about where they are in the file? Limiting programs to fixed-width, single-font text also seems like a historical artifact. (The Xerox Alto allowed full WYSIWYG text for program code.) Having to draw diagrams with ASCII graphics just seems wrong. Admittedly, these examples are somewhat trivial, but my point is that program structure is probably a local maximum, not the best possible solution.

mgummelt 7y ago
> Why can't methods (for instance) get displayed as convenient, without worrying about where they are in the file? Get displayed as convenient what? > Limiting programs to fixed-width, single-font text also seems like a historical artifact. (The Xerox Alto allowed full WYSIWYG text for program code.) Having to draw diagrams with ASCII graphics just seems wrong. I can imagine benefits of better diagrams, for documentation, but how would more fonts in the code help?
- Noumenon72 7y ago
  Comments could use native italics and links instead of HTML markup. More comment would fit on a line with a proportional font. Headings would be great for breaking up sections of code, and could be collapsible. Maybe linkable as well. Things that are arrays of arrays or tuples, like enums, could be tables. When you pass three functions to create an observer, there could be a table with columns "Parameter name, signature, implementation". Async code like observables and a thread's run method could be in a different font than code that executes right when you interpret it.
jack_h 7y ago
> It seems like there must be a way to treat text in a more flexible way without going to a full visual programming language. I've mentioned this a few times on past articles on HN, but I think the issue is we're marrying two different concepts with text based programming languages, namely presentation and representation. Consider - in an idealized context - HTML and CSS. One being the representation, the other being the presentation or more accurately how to present the representation. A user can change how the HTML is presented to them without changing the HTML directly. I think something like this would be useful for programming source code. So as a thought experiment for this in terms of programming, the source code would be some backing representation that you edit which can be rendered in any way a user desires, including back to regular text as we have now. Tooling (compilers/interpreters, version control, editors, etc) would deal primarily with the representation rather than the presentation. I think this would also solve a lot of problems that tooling ends up dealing with. Consider version control not having to deal with formatting changes because that's just an artifact of how a programmer chooses to render the representation rather than the representation itself. Autoformatters (gofmt, clang-format, etc) would be less about putting source code in a canonical format for the sake of tooling and more about rendering source code as text in a particular chosen way for individual programmers. Similar for tooling such as IDE code folding or refactoring, document generation, etc. This is actually something I have been pondering for a decade at this point. I have no idea how a system such as this could be implemented such that it is general and sound enough to be usable. But I still think it would be a neat way to program.
- sfifs 7y ago
  I think the problem emds up being that visual programming implementations I have seen over the years don't really make a moderately skilled programmer more productive or efficient. So the value ends up being in giving more people who are unskilled or less skilled in programming a way to express "programmatic thinking" and algorithms. I have taught dozens of kids scratch and that's a great application that makes programming accessible to "more" kids. At work, my team abstracts complex feature creation logic into KNIME components that our analysts (who struggle with Python programming) can mix and match and run analysis.
- GChevalier 7y ago
greggyb 7y ago
You might like Smalltalk. Programs are stored as images. An image holds the entire (fully introspectable, editable) runtime and your program. You can browse through your image with a powerful suite of built-in tools. Pieces of the image can be "filed out", or serialized to a file format. You can see an example at 15:00 of this video - some snippets of code and then showing the System Browser. https://www.youtube.com/watch?v=eGaKZBr0ga4 https://www.youtube.com/watch?v=eGaKZBr0ga4
sullyj3 7y ago
> Why can't methods (for instance) get displayed as convenient, without worrying about where they are in the file? This is something unison is playing with with their codebase manager. https://www.youtube.com/watch?v=gCWtkvDQ2ZI https://www.youtube.com/watch?v=gCWtkvDQ2ZI
- zubairq 7y ago
  Actually Pilot works in the same way. It treats all code as independent of the file system, identified by the h SHA256 of the content. https://github.com/zubairq/pilot https://github.com/zubairq/pilot
DonHopkins 7y ago
It's possible to make visual user interfaces to text based programming languages. And that's especially convenient for programming languages that are good at drawing graphics. Here's an interactive visual programming and debugging user interface to the PostScript programming language, implemented in the NeWS dialect of PostScript: https://medium.com/@donhopkins/the-shape-of-psiber-space-october-1989-19e2dfa4d91e https://medium.com/@donhopkins/the-shape-of-psiber-space-oct... The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989 Abstract: The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS. The PSIBER Space Deck is a programming tool that lets you graphically display, manipulate, and navigate the many PostScript data structures, programs, and processes living in the virtual memory space of NeWS. The Network extensible Window System (NeWS) is a multitasking object oriented PostScript programming environment. NeWS programs and data structures make up the window system kernel, the user interface toolkit, and even entire applications. The PSIBER Space Deck is one such application, written entirely in PostScript, the result of an experiment in using a graphical programming environment to construct an interactive visual user interface to itself.

by kens 7y ago

mgummelt 7y ago

> Why can't methods (for instance) get displayed as convenient, without worrying about where they are in the file? Get displayed as convenient what? > Limiting programs to fixed-width, single-font text also seems like a historical artifact. (The Xerox Alto allowed full WYSIWYG text for program code.) Having to draw diagrams with ASCII graphics just seems wrong. I can imagine benefits of better diagrams, for documentation, but how would more fonts in the code help?

Noumenon72 7y ago
Comments could use native italics and links instead of HTML markup. More comment would fit on a line with a proportional font. Headings would be great for breaking up sections of code, and could be collapsible. Maybe linkable as well. Things that are arrays of arrays or tuples, like enums, could be tables. When you pass three functions to create an observer, there could be a table with columns "Parameter name, signature, implementation". Async code like observables and a thread's run method could be in a different font than code that executes right when you interpret it.

jack_h 7y ago

> It seems like there must be a way to treat text in a more flexible way without going to a full visual programming language. I've mentioned this a few times on past articles on HN, but I think the issue is we're marrying two different concepts with text based programming languages, namely presentation and representation. Consider - in an idealized context - HTML and CSS. One being the representation, the other being the presentation or more accurately how to present the representation. A user can change how the HTML is presented to them without changing the HTML directly. I think something like this would be useful for programming source code. So as a thought experiment for this in terms of programming, the source code would be some backing representation that you edit which can be rendered in any way a user desires, including back to regular text as we have now. Tooling (compilers/interpreters, version control, editors, etc) would deal primarily with the representation rather than the presentation. I think this would also solve a lot of problems that tooling ends up dealing with. Consider version control not having to deal with formatting changes because that's just an artifact of how a programmer chooses to render the representation rather than the representation itself. Autoformatters (gofmt, clang-format, etc) would be less about putting source code in a canonical format for the sake of tooling and more about rendering source code as text in a particular chosen way for individual programmers. Similar for tooling such as IDE code folding or refactoring, document generation, etc. This is actually something I have been pondering for a decade at this point. I have no idea how a system such as this could be implemented such that it is general and sound enough to be usable. But I still think it would be a neat way to program.

sfifs 7y ago
I think the problem emds up being that visual programming implementations I have seen over the years don't really make a moderately skilled programmer more productive or efficient. So the value ends up being in giving more people who are unskilled or less skilled in programming a way to express "programmatic thinking" and algorithms. I have taught dozens of kids scratch and that's a great application that makes programming accessible to "more" kids. At work, my team abstracts complex feature creation logic into KNIME components that our analysts (who struggle with Python programming) can mix and match and run analysis.
GChevalier 7y ago

greggyb 7y ago

You might like Smalltalk. Programs are stored as images. An image holds the entire (fully introspectable, editable) runtime and your program. You can browse through your image with a powerful suite of built-in tools. Pieces of the image can be "filed out", or serialized to a file format. You can see an example at 15:00 of this video - some snippets of code and then showing the System Browser. https://www.youtube.com/watch?v=eGaKZBr0ga4 https://www.youtube.com/watch?v=eGaKZBr0ga4

sullyj3 7y ago

> Why can't methods (for instance) get displayed as convenient, without worrying about where they are in the file? This is something unison is playing with with their codebase manager. https://www.youtube.com/watch?v=gCWtkvDQ2ZI https://www.youtube.com/watch?v=gCWtkvDQ2ZI

zubairq 7y ago
Actually Pilot works in the same way. It treats all code as independent of the file system, identified by the h SHA256 of the content. https://github.com/zubairq/pilot https://github.com/zubairq/pilot

DonHopkins 7y ago

It's possible to make visual user interfaces to text based programming languages. And that's especially convenient for programming languages that are good at drawing graphics. Here's an interactive visual programming and debugging user interface to the PostScript programming language, implemented in the NeWS dialect of PostScript: https://medium.com/@donhopkins/the-shape-of-psiber-space-october-1989-19e2dfa4d91e https://medium.com/@donhopkins/the-shape-of-psiber-space-oct... The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989 Abstract: The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS. The PSIBER Space Deck is a programming tool that lets you graphically display, manipulate, and navigate the many PostScript data structures, programs, and processes living in the virtual memory space of NeWS. The Network extensible Window System (NeWS) is a multitasking object oriented PostScript programming environment. NeWS programs and data structures make up the window system kernel, the user interface toolkit, and even entire applications. The PSIBER Space Deck is one such application, written entirely in PostScript, the result of an experiment in using a graphical programming environment to construct an interactive visual user interface to itself.