Hacker News Reader

Comment by giraffe_lady | Hacker News Reader

Iiiinteresting. It reminds me of a hillel wayne thread from a while back that I remember poorly and can't find but will try to paraphrase.

It was like "programming languages and workflows are built around the state of having written code rather than writing code." I think the example was how in most languages you can remove a few chars or a symbol and put it in a 100% invalid state where none of the tools will work at all. A few seconds ago you had a bunch of type information, jump-to-definition, auto formatting etc, now you have a compiler error instead.

It really stuck with me because it described an experience so common I don't even really notice it anymore but really. What would it be like to work in a language that considered "non-functional" states still "valid" and tried to express what they knew about the gaps?

This is a very different idea but I feel like it's approaching some of the same concepts, in a way.

View on HN

I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version control commits are an attempt to hilight/preserve those working states.

Limiting deltas to working-only states would, I think, result in something akin to MIT's 'Scratch' language, where kids put together puzzle pieces - a program can only be wrong at a semantic level, never at a source code level. OTOH, refactoring power tools available in modern IDEs are a bit of a counter-argument in that they allow code transforms that don't usually make much of a semantic difference (eg. 'inline this', 'extract this as a variable', etc) But as you say, that's "written code" not "writing code".

For writing code, I think the closest current IDE feature to tylr would maybe be syntax hilighting. It'd be cool to maybe have some kind of 'expression hilighting' mode, and maybe an 'expression editor' mode with actions like tylr supports.

I mean, the closest I know to avoiding this is something like writing lisp with smartparen. This ensures the code is always syntactically valid, but it doesn't prevent you from partially typed function names like "filte".

However, I think that's a good thing. The alternative to partially typing out functions would be selecting them from a list or automatically having the editor fill in the most likely match from before the first letter is typed.

Both the latter would, if interrupted, convey less information than the partially typed out name.

Phrased differently: writing code will always be a matter of narrowing down the full namespace to the appropriate function. Partially typing it provides the human about the most information on where things are going, even if it's not as friendly on compilers.

So yeah, we could have compilers fill in the missing information to create a compiler-valid state from partial information, but what does that give us? A wildly incorrect program that's harder to fix?

Programming is writing code for humans that computers occasionally read, not the other way around. With today's focus on tooling, I feel like we have forgotten this.

Here's a flash of inspiration I had, produced by this thread, recent figure drawing practice, plus an iced latte: in the same way that there are identical lines one can draw that have different purposes to produce an image, there are identical characters one can type that have different purposes to produce a program.

That is, if you're observing from life, you might have some lines to broadly structure the image first: some angles and lengths, a grid, or an envelope shape. Then to develop connectedness and flow you might switch to drawing in sweeping gestures. Then you might switch again to 3D construction to refine the forms and make them align well, and finish by adding shading lines to render the lighting and details.

Gestural lines are powerful because they generate lots of proportional information: a straight line tells us a single angle and length, while a sweeping curve can be nearly infinite.

Right now when we type code, it's a little more like poking at the drawing, making little scribble lines everywhere. We don't have gestural lines, and the structural tools are also limited - we often have to erase and redo things because the "proportions" are off.

While I don't know if the literal translation of this to "programming with a stylus" would work out, it's definitely on my mind now.

> What would it be like to work in a language that considered "non-functional" states still "valid" and tried to express what they knew about the gaps?

The closest I can think of is HTML, where browsers try their best to resolve small syntax errors. I suspect this is easier to accomplish with markup than with most programming languages.

Isn't this really dependent on the implementation? Language servers (at least typescript in VScode last I checked) still provided all of the features you mention even when there is a blatant syntax error. The only lost information is from within the section of code that can't be parsed due to the error.

It seems to me that this is much more dependent on the language specification rather than on the implementation of anything. In case of a parse error, you may not be able to recover correctly the parsing of any code beyond the error. Take for example the case of an omitted right brace/parenthesis/end keyword/whatever terminates the body of a function in your language. In a language that only allows top-level function definitions, upon encountering a beginning of another function definition, you could recover parsing from there since it couldn't possibly have been inside the body of a previous function. That function will then be recognized by your tools as a globally named object of the language (or, available in its respective module, should your language have modules). But in a language where local function definitions are allowed, you can't do that since that function could plausibly have been a local in the "previous" (actually, enclosing) function with the parse error. You simply don't know it it was supposed to be a local definition or a top-level one.

> In case of a parse error, you may not be able to recover correctly the parsing of any code beyond the error.

Of course, ambiguous syntax will obscure any information beyond what can be understood (short of having a compiler track changes between runs).

Some languages / compilers can recover after a parse error. Going back to the ts language server, if you introduce a single quote, unclosed, nothing works until the end of the line (single quoted strings cannot be multiline)

Both before the quote and after that line, however, features such as auto-importing and autocompletion still work as expected.

This is an issue of where the boundaries of the ambiguity lie (what is possible) and the implementation (what actually happens). I suspect many language / compiler / IDE tools fall in different places on the spectrum of possible and works to possible but not implemented. My hunch is that more and more, tools are getting closer to the "possible and works" side of things.

Just riffing on what you all are saying, maybe an, "undo to last working state" might be, for many current environments, an easy to add minor improvement. It doesn't seem that hard to keep track of the last point in the undo stack before it all went sideways.

malleable code that remains valid on manipulation. Is there such outside graphical programming?

Reply on news.ycombinator.com