https://futureofcoding.org/ logo
Join Slack
Powered by
I feel like a lot of people in this group think th...
# thinking-together
f
I feel like a lot of people in this group think that storing programs as text is probably not a good idea. Leaving editing UX aside, what counter-arguments can you come up with or have you heard from others?
"But all our tools work with text" is probably the one I've heard most often.
☝️ 1
d
Language is the material of thought. In the most literal sense, it's our most meaningful expression. I'm cool with an alternative filing system (maybe the text should go in a database on not a text blob), but I don't think we'll ever surpass language, and to try would simply create a new language.
On the other hand, all languages are hieroglyphic in their roots, which is to say that the meaning of the symbols were once not so abstract as they are now. In a sense, the visual programming tools are returning to a more hieroglyphic approach, which I think is a fine effort. But the tendency of language seems to be towards abstraction through what I think is safe to call poetry.
k
The future of programming may well be more visual/graphical. But text doesn't feel like the biggest bottleneck at the moment in getting from here to there. https://futureofcoding.slack.com/archives/C5T9GPWFL/p1547874166368000?thread_ts=1547862690.360400&cid=C5T9GPWFL
d
My language, Curv, is for making graphics. So text alone is not enough. The contents of a PNG image file constitute a literal image constant in Curv. In order to work within the limitations of the Unix file system, I support several file formats for Curv source files: * A text file, *.curv, using a traditional programming language syntax. It contains an expression, and evaluates to whatever the expression returns. * A directory evaluates to a record value, with one field for each file in the directory. The filename of a directory component is mapped to a field name in the record value, and the contents of the file are evaluated to the field value. * An image file, *.png, evaluates to an image value.
👍 1
s
Storing programs as text isn't the same as using language. You could have language, but not store programs as text, or in fact not store programs at all. E.g. you could use language to create projections of behavior that interest you. 
show all causality paths that connect event E to any effect on entity Y
(computer displays a text list) You could use language to further edit the behavior via the projection 
try remove path 3
(computer shows options that would do this, and a summary unrelated effects each option would have, including tests/constraints that would now fail) 
apply option 2
(etc.) Above is a text-only interaction example where there is the notion of 'stored text programs' doesn't exist. You just modify the stored behavior via some text query language. It could also be imagined as a hybrid text/graphical with button clicks instead of text queries, etc. There's many different dimensions when discussing text. 'Interacting via text' doesn't have to imply 'store a large text expression as the program'. In fact many visual interaction mediums also use text in a bunch of places.
👏 3
Portability is the main counter-argument I've seen. I think it's valid from the 'situated' perspective. A related argument is ease of programmatic inspection and generation. "I'll need a special lib to read your binary format but I can just open() a read() a text file".
👍 1
i
I think it's easier to make a text-based UI than it is to make a GUI, especially for programmers (who stereotypically don't have much in the way of visual design chops). So for that reason there are more people at the intersection of "interesting ideas about programming" and "ability to realize those ideas" when the ideas or realization take the form of text. For that reason, we see more rapid progress in text-based. But a consequence of that is that visual-based programming ideas are under-explored, which is probably why this community is so excited about them. Not sure if "it's harder and slower and more costly" is a legitimate counter argument or a just a justification. In any case, I've planted my flag firmly in the "visual languages are more fun" camp so it's hard to come up with good devil's advocate arguments over the incessant neighing of my horse in this race.
😄 2
d
For me, it's about "what is the best representation?" for each thing. For a program (or part of it) that draws shapes, that's better "programmed" by drawing shapes. Or maybe a whole software system is better expressed as a diagram. The point is that when you read or write a program, you have to read and read and think and think, all the while building up a model in your head of it. But what if that model or structure was obvious at a glance? See the "Dump the parts bucket onto the floor" section (and animated images) of the following: http://worrydream.com/LearnableProgramming/ Also see: https://www.google.com/amp/s/programmingmadecomplicated.wordpress.com/2017/10/29/introducing-drw-a-useful-tool-to-solve-a-practical-problem/amp/ What if programming could be like the following, but for logic instead of shapes? (The templating could act as a function or class): http://worrydream.com/DrawingDynamicVisualizationsTalk Or for a REALLY deep dive into what "obvious at a glance" means (or arranging your code such that you don't have to do lots of (mental) "interaction" to dig out an understanding of it), see this very long (but very worthwhile) article: http://worrydream.com/MagicInk
... Or in other words, explore what you can on Bret Victor and Alan Kay, and you'll get an idea of what most of us are mostly after :)
i
For a program (or part of it) that draws shapes, that's better "programmed" by drawing shapes.
I've heard this argument many times, and I agree the some facets of it, but... It suggests that a program that is about generating text is better programmed by writing text. It suggests that a program about making sound is better programmed by.. playing an instrument? The logic breaks down pretty quickly when you start looking at more wild examples. It puts visual languages into a box that they never seem to grow out of — "Sure, they're good when you're working with visual stuff — artsy stuff — but they aren't good when making an [ETL pipeline / SaaS app / PoS terminal / etc]." I think this is a bit of No True Scotsman. I'd argue that the reason many visual programming languages are made for artistic uses is not because VPLs are well suited to graphics, but rather because there's some classism going on — "real" text programming for real programmers, and "that VPL stuff" for non-programmers. After all, one of the richest VPLs is Max/MSP — a tool primarily for working with sound, not imagery. ---- Other than that one line, I agree with everything else you said, and I know that in general we're on the same page about all this stuff. I'm just trying to point out a weird critique that comes up pretty regularly that doesn't seem to hold water.
w
Parsing tends to be a little tedious.
d
Ooh, good point! Maybe this: making a program that facilitates a thing, is not the same as actually doing that thing yourself; so whatever the best representation is. Sometimes sheet music or visualized waveforms are better than recording and replaying actual sound. But in many many cases (including the one I just mentioned), visualization of some kind is way better, because of the ability of the human mind (visual cortex) to process visual information almost immediately. (That's what "Magic Ink" is mainly about: identifying what info is valuable to get at, and using visual layout or organization to make it immediately understandable, rather than having to dig and work and manually compare, etc.)
d
Since the question was about how programs are stored, not about UX, here's a link about the benefits of a new binary representation for Javascript source code. https://yoric.github.io/post/binary-ast-newsletter-1/
👍 1
w
We could say that plaintext is nice because you can "just" 
cat
it, etc. However, a little experience has taught us all that there's nothing "just" about text encodings. So even the text itself (let alone programs written in text) require quite a bit of tooling.
d
A number of years ago, I had too much free time, so I redesigned the entire software stack from the OS up to the internet. (Don't look for this on github: the project was too ambitious to implement.) I decided that the Unix decision to represent most data as ASCII text is holding us back. My replacement was a variant on S-expressions, called T-code, which was hierarchical, and could encode anything: documents, source code, databases, images, etc. Instead of a file system, your hard drive is formatted as a T-Code store. Network protocols would be serialized T-Code, etc. The JavaScript Binary AST reminded me of this old idea. Because Curv represents source code as Unix files and directories, image literals are restricted by the syntax to only appear as initializers for record fields. If I could use T-Code instead to encode source code, then this limitation would disappear, and image literals could appear in any subexpression.
❤️ 4
j
d
@jonathoda That blog post starts out with an image of a Sumerian stone tablet inscribed with 2 dimensional, pictographic writing -- more similar to diagram-based visual programming languages than 1D alphabetic text. And I get the point: 2D pictograms, ideograms, logograms, mathematical diagrams, math notation and 1D alphabet text all exist on the same continuum, and are arguably all forms of "text". But "text" also refers to a particular file format: a stream of bytes representing ASCII characters or UTF-8 code units, with newline characters arbitrarily inserted by hand every 80 characters or so, for compatibility with ancient tools like vi, grep and diff, originally descended from tools for processing 80-character punch card data. Why are we stuck with this ancient text file format? It's a poor fit to the modern abstraction of Text. Why do we still use newlines? Newline is a control code for the ASR 33 Teletype, but we don't live in that world any more. Abstract Text isn't a linear sequence of lines, it is hierarchical: <body> contains <h1> contains <h2> contains <p> contains <a>. Modern Text can contain inline images, but the text file format doesn't support this, so the Unicode committee is helpfully providing a workaround by giving us a large clipart library embedded in the Unicode standard. It is time to move on.
❤️ 1
j
@Doug Moen I agree that ASCII text seems like an obsolete constraint. But Graydon’s point is that no one has beaten text yet. We’ve been complaining about text for decades now but we haven’t come up with something better. Time to put up or shut up.
😏 1
👏 1
d
I distinguished two meanings of the word "text". All of Graydon's points apply to Text in the abstract. None of his benefits require the file format I am criticizing.
k
I like Doug's idea above of redesigning the OS to better support Text. @wtaysom's point about 
cat
only exists because of syscalls built into Unix for working with ASCII. Rather surprisingly, I recently discovered that Unix was originally designed as a word-processing and type-setting system: https://web.archive.org/web/20190421021112/http://zge.us.to/txt/unix-harmful.html. A slightly different historical path may well have given us a very different set of primitive operations for text.
s
Agree strongly with @Doug Moen here. There are a lot of meanings in the term 'text' and Graydon's write-up doesn't separate them out but just makes a blanket statement. Because text is a good way to convey concepts to humans, it's useful to have it in the UI. But there's a leap from that to saying the UI should solely consist of lines of text, with no other structure. There's a further leap from that to storing those lines as-is in files.
🍰 1
💯 1
@Doug Moen the T-code OS idea is very interesting. Do you have any pointers to write-ups or retrospectives?
f
Very interesting discussion! Btw, does anyone here really "think" in text / words? For me, it really depends on the task. Most often it's a mix of words, diagrams, tables, concepts and structures I can't even describe properly. I use text / words for communicating ideas mainly because that's what most communication channels support. Speaking and text messages just work with text / words. If there was a way in which I could directly communicate my thoughts to someone else without encoding them as words first, I would probably prefer that because there wouldn't be as much "loss in translation". My hand-written notes aren't purely textual and I can express my thoughts much better on paper because of that flexibility.
Almost all text is ambiguous in some way and needs interpretation. Humans are really good at this (but not even close to perfect). Computers aren't good at dealing with ambiguities (and I'd argue they shouldn't have to deal with ambiguities at all). Because programs stored as text are ambiguous (e.g. "Which version of Python does this script require?", "Where do I find the library 'numpy'? And what version do I need?"), we invented a whole bunch of bolt-on tools (e.g. dependency management) and rules so that our programs become less ambiguous. It's clear that these ambiguities need to be resolved, but we can choose when to do that. I'd argue that it should happen as soon as possible. For example, your editor should know that you write Python 3.7 by default and encode that in the storage representation unless you specify something else. The representation shared between people should be unambiguous. Think of it like talking to a (human) assistant. If you tell them "Please call Mary and tell her that Tom wants to meet her at 8PM", the assistant would probably ask which 'Tom' you meant and would assume that the time was referring to your current time zone. Using the additional information, the assistant could inform Mary (assuming that 'Mary' is unambiguous). If they'd just do the call (without asking for clarification), Mary would have to guess the exact meaning of 'Tom' and the time. In programming we're guessing and working around ambiguity issues all the time and I wonder if another storage representation could solve this.
s
I read somewhere (cannot find the source) that human cognition has two main areas - linguistic and spacial. I don't think exclusively in language but I cannot thing without language either. Sometimes there's a back and forth where there's a vague structural idea but it has to be expressed in language to refine it. I'm also reading 'Metaphors We Live By' (Lakoff) and am getting convinced that a lot of understanding and reasoning is about placing some ideas into metaphors of various kinds. For instance the 'container' metaphor - something we tangibly experience when working with a physical box of objects - pops up all over the place in virtual concepts as well.
d
MVC is about this. As Jim Coplien puts it, (paraphrase) "I have this idea I want to communicate, and what I really want is to reach into your head and mess with your neurons so you have it too. But that would be messy, so I have to do it through this interface" (gestures to his face and hands). Communication between human & computer has to be done through views and controllers, and sometimes language.
w
People are really great at picking a sensible interpretation from ambiguity, in fact, even if wrong words or phrasing is used, people will repair it. This is an essential skill for spoken speech where the signal is often, really, objectively off.
👍 1
i
We're all just waiting for the James Joyce of visual programming languages to come along, to make an esolang that almost makes sense if you devote your life to studying it, speak multiple languages, collaborate with other scholars, and never really grow out of that "it's fun to try when you're in college" phase even though you probably should've.
w
@Ivan Reese (off topic) for video games, I've at least found the Witness, which reads shocking like Joyce to me: same sort of structural, referential, ridiculous, sublime spirit. Where Ulysses has Episode 14 (along with all the other styles across episodes), the Witness attempts to imitate the history of video games. And of course the Witness references the Odyssey along with a whole high and low kitschy stack of everything else.
(And, like Joyce, the Witness is not for everyone.)
g
the idea of pouring out legos makes me wonder if AR and hand based input might be a step. I'd argue a big problem with VPLs is trying to interact with them via a mouse and keyboard, trackpad and keyboard, or touchscreen. Virtual 3D items in my AR vision that I can manipulate with my fingers "might" help remove some of that friction. OTOH it's so easy to manipulate text. Search and replace with regex. Column select or multi-cursor editing. Those things are arguably harder in VPLs though maybe VPLs could make them less important. Autodesk Maya does something I've seen no other system do (don't have that much experience with other systems though). You can select any objects and then pick "spreadsheet view". Each row is an object, each column is a field. This lets you edit fields across objects to some extent. you can select a column or individual cells and type +10 and it will add 10 to each selected cell. Or *12 to multiply by 12. If nothing else it gives an easy way to see values of all objects. Objects don't have to be homogeneous but of course it's less common to select non-homogeneous objects.
2 Views
Open in Slack
PreviousNext
Powered by