4 ms·

> Programs should be valid as they are typed. That would be nice if devs always wrote code sequentially, i.e. left to right, one character at a time, one line

by kmoser 1y ago

> Programs should be valid as they are typed. That would be nice if devs always wrote code sequentially, i.e. left to right, one character at a time, one line at a time. But the reality is that we often jump around, filling in some things while leaving other things unfinished until we get back to them. Sometimes I'll write code that operates on a variable, then a minute later go back and declare that variable (perhaps assigning it a test value).

nottorp 1y ago
Exactly. You only write code sequentially when it's a new file. If i decide to add a new field to some class, i won't necessarily go to the class definition first, I'll probably write the code using that field because that's where the IDE was when i got the idea. If I want to enhance some condition checking, i'll go through a phase where the piece of code isn't valid while I'm rearranging ifs and elses.
- smohare 1y ago
  [dead]
- AnimalMuppet 1y ago
  > You only write code sequentially when it's a new file. Often, not even then.
f1shy 1y ago
Yes. Seems like an arbitrary limitation to force it.
chrismorgan 1y ago
That’s not quite what the article’s about, though it’s interesting too.
slowmovintarget 1y ago
This is a "let 'im cook" instance. Reading through the article, the author makes the argument for the philosophy of progressive disclosure. The last paragraph brings it together and it's a reasonable take: > When you’ve typed text, the program is valid. When you’ve typed text.split(" "), the program is valid. When you’ve typed text.split(" ").map(word => word.length), the program is valid. Since the program is valid as you build it up, your editor is able to help you out. If you had a REPL, you could even see the result as you type your program out. In the age of CoPilot and agent coders I'm not so sure how important the ergonomics still are, though I dare say coding an LSP would certainly make one happy with the argument.
dkarl 1y ago
Code gets written once and read dozens or hundreds of times. Code that can be read sequentially is faster and easier to read than code that requires jumping around.
- igouy 1y ago
  And @kmoser did not say code should not be read sequentially.
- jibal 1y ago
  non sequitur
astrange 1y ago
I agree with this, but it leads to another principle that too many languages violate - it shouldn't fail to compile just because you haven't finished writing it! It should fail in some other non-blocking way. But some languages just won't let you do that, because they put in errors for missing returns or unused variables.
- Terr_ 1y ago
  I feel that's a use case for compiler flags that convert warnings to errors or vice-versa, where the same source-code can either be "good enough to experiment with" or "not ready for release" depending on the context.
- kmoser 1y ago
  How is it supposed to compile if you've written something syntactically invalid? You can make the argument that the compiler could interpret it in (perhaps even arbitrary) valid way that constitutes a valid syntax, but that's almost worse: rather than being chided with compiler warnings, you now end up with code that compiles but executes indeterminately.
  - disconcision 1y ago
    there are approaches to ensure you always or almost always have syntactic validity, e.g. structured editing or error correcting parsing, though of course it's true that the more permissive the system is the more tortured some of the syntactic 'corrections' must be in extreme cases. the approach we're taking with http://hazel.org http://hazel.org (which we approximate but don't fully succeed at yet) is: allow normal-ish typing, always correct the code enough to be ran/typechecked, but insert placeholders/decorations to telegraph the parse structure that we're using in case of errors or incompleteness.
    - mackeye 1y ago
      i saw hazel mentioned forever ago in an eecs 203 lecture and it sent me on a multi-year fp/type theory rabbit hole :) thanks for your work on it!
layer8 1y ago
Also, mutual recursion. ;)
PaulHoule 1y ago
It's definitely a minor annoyance for me that IDEs assume that I type things in a different order than I really do.

by kmoser 1y ago

nottorp 1y ago

Exactly. You only write code sequentially when it's a new file. If i decide to add a new field to some class, i won't necessarily go to the class definition first, I'll probably write the code using that field because that's where the IDE was when i got the idea. If I want to enhance some condition checking, i'll go through a phase where the piece of code isn't valid while I'm rearranging ifs and elses.

smohare 1y ago
[dead]
AnimalMuppet 1y ago
> You only write code sequentially when it's a new file. Often, not even then.

f1shy 1y ago

Yes. Seems like an arbitrary limitation to force it.

chrismorgan 1y ago

That’s not quite what the article’s about, though it’s interesting too.

slowmovintarget 1y ago

This is a "let 'im cook" instance. Reading through the article, the author makes the argument for the philosophy of progressive disclosure. The last paragraph brings it together and it's a reasonable take: > When you’ve typed text, the program is valid. When you’ve typed text.split(" "), the program is valid. When you’ve typed text.split(" ").map(word => word.length), the program is valid. Since the program is valid as you build it up, your editor is able to help you out. If you had a REPL, you could even see the result as you type your program out. In the age of CoPilot and agent coders I'm not so sure how important the ergonomics still are, though I dare say coding an LSP would certainly make one happy with the argument.

dkarl 1y ago

Code gets written once and read dozens or hundreds of times. Code that can be read sequentially is faster and easier to read than code that requires jumping around.

igouy 1y ago
And @kmoser did not say code should not be read sequentially.
jibal 1y ago
non sequitur

astrange 1y ago

I agree with this, but it leads to another principle that too many languages violate - it shouldn't fail to compile just because you haven't finished writing it! It should fail in some other non-blocking way. But some languages just won't let you do that, because they put in errors for missing returns or unused variables.

Terr_ 1y ago
I feel that's a use case for compiler flags that convert warnings to errors or vice-versa, where the same source-code can either be "good enough to experiment with" or "not ready for release" depending on the context.
kmoser 1y ago
How is it supposed to compile if you've written something syntactically invalid? You can make the argument that the compiler could interpret it in (perhaps even arbitrary) valid way that constitutes a valid syntax, but that's almost worse: rather than being chided with compiler warnings, you now end up with code that compiles but executes indeterminately.
- disconcision 1y ago
  there are approaches to ensure you always or almost always have syntactic validity, e.g. structured editing or error correcting parsing, though of course it's true that the more permissive the system is the more tortured some of the syntactic 'corrections' must be in extreme cases. the approach we're taking with http://hazel.org http://hazel.org (which we approximate but don't fully succeed at yet) is: allow normal-ish typing, always correct the code enough to be ran/typechecked, but insert placeholders/decorations to telegraph the parse structure that we're using in case of errors or incompleteness.
  - mackeye 1y ago
    i saw hazel mentioned forever ago in an eecs 203 lecture and it sent me on a multi-year fp/type theory rabbit hole :) thanks for your work on it!

layer8 1y ago

Also, mutual recursion. ;)

PaulHoule 1y ago

It's definitely a minor annoyance for me that IDEs assume that I type things in a different order than I really do.