4 ms·

> Should we all just be programming on pen and paper because that’s lower down the progression stack and has less chance of failing? Yes. Not because of the r

> Should we all just be programming on pen and paper because that’s lower down the progression stack and has less chance of failing? Yes. Not because of the resiliency (it's hard to imagine a failure mode where pen-and-paper programming would be the only option) but because it makes you better at your craft.

seanmcdirmid 5y ago
I mean, sure. We should always know the stack down to the electrons. Not only should we learn to code on paper, but build our own adders from primitive boolean logic gates. But this doesn't really follow (most of) us out of our BS computer science program (or perhaps until we have to do programming interviews).
- goblin89 5y ago
  I’m of two camps. On one hand, I don’t use fonts with ligatures (I use Triplicate by the OP, very happy with it), and usually work without colorful syntax highlighting. The assumption is that code is read more often than it is written, and I have no idea how my code will be read in future—thus the rule of thumb: if I understand it when it’s plain text monochrome, then the next maintainer (or future me) will be able to understand it with syntax highlighting on. I’m already biased to understand my own code more easily than anyone else, so I shouldn’t need extra visual aids if I’m not the only one who’ll work with it. Plus, ligatures, syntax highlighting and auto-completion strike me as, in a sense, attempts to create a rudimentary GUI (TUI) to AST on top of plain text—but due to limited capabilities to work with it’s always semi-broken: syntax highlighting is off, ligatures have false positives, etc. On the other hand, the idea that “we must keep using plain text” strikes me as somewhat stuck in the past. The age of syntax-tree-driven, program-as-structured-data version control and editing capabilities must not be far off. At that point, we’ll likely get much greater flexibility—highlighting/autocompleting not just tokens but entire patterns (for adequately structured programs), exposing new refactoring operations, and more. We might start seeing cases where a genius high-level architect may not be that proficient at editing programs in plain text, and it’ll be obvious in hindsight. (As an aside, I’m a little sour that GitHub/MS threw resources onto black-box ethically questionable Copilot rather than structured code.) On the third hand (one foot?), there’s something to be learned from ligature+syntax highlighting+linting text-based authoring experience as a GUI—generalizing a little, we don’t have many other GUIs that attempt to present source data nicely while maintaining it zero-effort for you to drop into low-level edit mode. I wish whatever next-gen structured code authoring experience comes next has implementations that preserve this feature.
  - seanmcdirmid 5y ago
    Code completion is basically the way you get structured code capabilities in a non-structured editor. Ah, but it was invented to solve an input problem in Alice Pascal (circa 1985) which was totally a structured programming environment, so in a way code completion is a product of the environments you are wishing for.
    - goblin89 5y ago
      I don’t know if I’m “wishing for” such environments, I just strongly suspect they will arrive (or they technically should, if they overcome industry’s inertia). ALICE offered structured editing in a world where graphical output was so limited (and the lacking capability to just enter text in freeform was definitely a dealbreaker). I wonder how such an IDE could look today if rethought from fundamentals after all the advances in making and displaying GUIs.
      - seanmcdirmid 5y ago
        They've been arriving for the last few decades, but haven't been successful yet. No one has really thought through a fluid efficient editing experience for them that can leverage the benefits of structure without the stilted input entry that the structure seems to imply so far...and our understanding of UI hasn't gotten much better than it was before. Someone might crack it someday, I hope.
        goblin89 5y ago
        The problem is versioning code as structured data. It is not yet here, but there are very recent advances (Pijul et al). Freed from the shackles of LoC, GUIs can do all sorts of magic with structured.
  - CRConrad 5y ago
    > On the third hand (one foot?) OTGH, "on the gripping hand". Like many 1980s - 90s online idioms a science fiction reference, in this case to https://en.wikipedia.org/wiki/The_Gripping_Hand https://en.wikipedia.org/wiki/The_Gripping_Hand
KarlKemp 5y ago
I wish people wouldn't indulge in these luddite fantasies of some ancient caste of ninja programmers. It's blatantly wrong to the point where I'm not sure if the above is not meant as a joke. It's also insincere: do you regularly write out code with pen & paper? No, of course not. Nobody does. Just like nobody reads all the fine print, checks the emergency exits every time they enter a building, has an emergency drinking water reservoir, or a go-bag for volcano emergencies: these are teenage fantasies of what grown-up life should be like. Believing and propagating these ideas only sets you and your listeners up for failure.
- couchand 5y ago
  I spend a lot of time thinking through problems with pen and paper, and also highlighter and printer, and whiteboard. I've found this class of tools often lets me focus on a problem with less distraction. It's not always the right tool, and of course the code must be typed up sooner or later. I often work in environments where the development cycle time is terribly slow for one reason or another, which puts a premium on thinking through things ahead of time.

seanmcdirmid 5y ago

I mean, sure. We should always know the stack down to the electrons. Not only should we learn to code on paper, but build our own adders from primitive boolean logic gates. But this doesn't really follow (most of) us out of our BS computer science program (or perhaps until we have to do programming interviews).

goblin89 5y ago
I’m of two camps. On one hand, I don’t use fonts with ligatures (I use Triplicate by the OP, very happy with it), and usually work without colorful syntax highlighting. The assumption is that code is read more often than it is written, and I have no idea how my code will be read in future—thus the rule of thumb: if I understand it when it’s plain text monochrome, then the next maintainer (or future me) will be able to understand it with syntax highlighting on. I’m already biased to understand my own code more easily than anyone else, so I shouldn’t need extra visual aids if I’m not the only one who’ll work with it. Plus, ligatures, syntax highlighting and auto-completion strike me as, in a sense, attempts to create a rudimentary GUI (TUI) to AST on top of plain text—but due to limited capabilities to work with it’s always semi-broken: syntax highlighting is off, ligatures have false positives, etc. On the other hand, the idea that “we must keep using plain text” strikes me as somewhat stuck in the past. The age of syntax-tree-driven, program-as-structured-data version control and editing capabilities must not be far off. At that point, we’ll likely get much greater flexibility—highlighting/autocompleting not just tokens but entire patterns (for adequately structured programs), exposing new refactoring operations, and more. We might start seeing cases where a genius high-level architect may not be that proficient at editing programs in plain text, and it’ll be obvious in hindsight. (As an aside, I’m a little sour that GitHub/MS threw resources onto black-box ethically questionable Copilot rather than structured code.) On the third hand (one foot?), there’s something to be learned from ligature+syntax highlighting+linting text-based authoring experience as a GUI—generalizing a little, we don’t have many other GUIs that attempt to present source data nicely while maintaining it zero-effort for you to drop into low-level edit mode. I wish whatever next-gen structured code authoring experience comes next has implementations that preserve this feature.
- seanmcdirmid 5y ago
  Code completion is basically the way you get structured code capabilities in a non-structured editor. Ah, but it was invented to solve an input problem in Alice Pascal (circa 1985) which was totally a structured programming environment, so in a way code completion is a product of the environments you are wishing for.
  - goblin89 5y ago
    I don’t know if I’m “wishing for” such environments, I just strongly suspect they will arrive (or they technically should, if they overcome industry’s inertia). ALICE offered structured editing in a world where graphical output was so limited (and the lacking capability to just enter text in freeform was definitely a dealbreaker). I wonder how such an IDE could look today if rethought from fundamentals after all the advances in making and displaying GUIs.
    - seanmcdirmid 5y ago
      They've been arriving for the last few decades, but haven't been successful yet. No one has really thought through a fluid efficient editing experience for them that can leverage the benefits of structure without the stilted input entry that the structure seems to imply so far...and our understanding of UI hasn't gotten much better than it was before. Someone might crack it someday, I hope.
      - goblin89 5y ago
        The problem is versioning code as structured data. It is not yet here, but there are very recent advances (Pijul et al). Freed from the shackles of LoC, GUIs can do all sorts of magic with structured.
- CRConrad 5y ago
  > On the third hand (one foot?) OTGH, "on the gripping hand". Like many 1980s - 90s online idioms a science fiction reference, in this case to https://en.wikipedia.org/wiki/The_Gripping_Hand https://en.wikipedia.org/wiki/The_Gripping_Hand

KarlKemp 5y ago

I wish people wouldn't indulge in these luddite fantasies of some ancient caste of ninja programmers. It's blatantly wrong to the point where I'm not sure if the above is not meant as a joke. It's also insincere: do you regularly write out code with pen & paper? No, of course not. Nobody does. Just like nobody reads all the fine print, checks the emergency exits every time they enter a building, has an emergency drinking water reservoir, or a go-bag for volcano emergencies: these are teenage fantasies of what grown-up life should be like. Believing and propagating these ideas only sets you and your listeners up for failure.

couchand 5y ago
I spend a lot of time thinking through problems with pen and paper, and also highlighter and printer, and whiteboard. I've found this class of tools often lets me focus on a problem with less distraction. It's not always the right tool, and of course the code must be typed up sooner or later. I often work in environments where the development cycle time is terribly slow for one reason or another, which puts a premium on thinking through things ahead of time.