Live data from Hacker News

Cursorless – A spoken language for structural code editing

github.com

1–10 of 73 posts

Re: Cursorless – A spoken language for structural code editing

#6
post #4

I find it annoying that they are not using the standard phoenetic alphabet

from their youtube comment:

> Good question. For efficiency, we try to keep commonly used terms such as letters as short as possible. Note that the words we use for letters all one syllable, whereas the NATO phonetic alphabet are mostly two syllables. The words we use for spelling are also chosen so that they can be chained together easily and quickly, eg “harp each look look odd”. Easy to say quickly without slurring

Re: Cursorless – A spoken language for structural code editing

#7
This kind of work is also fantastic for those who have limited mobility or use of hands. On top of that, it's also a comforting peace of mind for the rest of us that should we ever e.g. lose our hands in a car collision, we might still have a successful path forward in our programming careers and passions.

Reminds me of a talk I once saw where a developer developed arthritis and couldn't program effectively anymore, so he developed an almost "verbal vim" plugin for vim (or was it emacs?) that allowed him to write/edit code quickly using verbal utterances. I forget what that project was, but I wonder how these two compare.

Re: Cursorless – A spoken language for structural code editing

#8
post #3

Imho text editing speed is not an issue for programmers.

And TDD is bad because it requires too much of typing /sarcasm

TDD is bad because it introduces distracting busywork. The actual typing isn't the actual problem.

In terms of just typing, I could probably produce something like 50,000 lines of code in a 40 hour work week in a moderately verbose programming language. In practice I'll probably crank out somewhere between 1000-5000.

It's the thinking that is slow. It's made even slower by adding additional tasks and context switching.

Re: Cursorless – A spoken language for structural code editing

#10

Imho text editing speed is not an issue for programmers.

It’s more complicated than that I think. You don’t spend much time typing, but how much does the time you spend (and the cognitive load of) typing deconstruct the mental architecture you’ve created to solve a problem?

This is at the core of why vim/others are still so popular. The micro-gains in typing efficiency translate to much more efficient problem solving because you don’t “lose your place” within your mental process. I think the same would extend to cursorless.

Post reply on HN