3 ms·
Has anyone tried this with coding? It looks like this is very focused towards writing English, which is fine, but as someone who spends a good chunk of my day
by tombert 5y ago
Has anyone tried this with coding? It looks like this is very focused towards writing English, which is fine, but as someone who spends a good chunk of my day around code editors, a keyboard that is crap for code editing is a non-starter.
However, if it's good for that, I will probably be buying one.
- rappatic 5y agoHe posted an earlier video on his TikTok account showcasing the device's coding capabilities. I don't know if the videos he posts are entirely reliable (eg. as another commenter mentioned, he claimed a 500 wpm typing speed by typing one memorized sentence). I do know that it needs autocorrect (built-in) to work at high WPM which doesn't seem great for coding which might use nontraditional words and spellings. Personally it seems like it would be too great a learning curve for not enough benefit, given that no software is designed for devices like these. Maybe if this somehow takes off in the future.
- tombert 5y agoI'm gonna bite the bullet and buy one, I think. I'm ok with a "good enough" coding experience, and I never bought myself a Birthday/Xmas present last year. This will work.
- ekimekim 5y ago> chorded typing allows the users to input several letters at the same time and have a computer program generate a predicted word. Instead of typing h e l l o, a chorded typer mashes h, e, l, and o to produce the word. It sounds like it relies heavily on autocomplete, which means it's unlikely to be useful for coding instead of just English text.
- cwp 5y agoNo, that means it's likely very useful for coding instead of English. You just need a custom dictionary. Code has a smaller vocabulary than prose, even with the domain-specific words that get used as identifiers . You could probably do pretty well with a dictionary that just has all the keywords in your favorite language, plus some common variable names. Heck I bet it'd be a win just to make the punctuation used in code have convenient chords.
- __MatrixMan__ 5y agoSeems like it would be better to have the device be dictionary agnostic and leave it to your editor do know whether you're writing a comment, or code, or a string containing sql...
- tombert 5y agoI wonder if it would make sense to latch into the syntax highlighter for something like Vim. Most syntax highlighters have a reasonable understanding of what context you are currently in, so conceivably the device could, for example, see that I'm inside a comment and revert to vanilla English, and then see that I'm back in code and change to F#.
- __MatrixMan__ 5y agoI think it would. It seems like you'd want some amount of symmetry between contexts, otherwise learning separate ones would be too difficult. Like the gesture for python's "create a for loop" would align with the english word "repeat" and in functional languages it might map to some manipulation that sets up recursion with a shortened list. Actually coming up with a list of such a list of abstractions for app developers to map actions onto sounds like a dissertation for some psychologist somewhere.
- a-dub 5y agoi don't think there's anything to gain here that you don't already get with good autocompletion. i wonder how a trained stenographer on a chorded keyboard would compare to a trained typist with a good english language model backed autocomplete and a ui built for speed on a classic qwerty keyboard.
- tombert 5y agoI'd be ok with it being "as good" as my current coding setup, at least if it improves my other typing speed. A vast majority of my correspondence these days involves me typing (as I've made , so being able to speed that up would still be cool, though I doubt it's going to be a categorical difference in my day-to-day life.
- a-dub 5y agocurious how it will work out. you'll have to learn new chords for the standard alphanumeric characters and then a chunking/chording scheme where the space of chunking schemes and associated chords for computing and coding is vast. my understanding is that classic stenography is actually phonetic. so the chords match up to phonemes or phoneme like chunks which are then postprocessed to reconstruct english text. a new approach using english language could be more data driven. a simple mapping could be one chord to one word with words sorted by frequency and easier chords assigned first. more complicated approaches involve chunking up the words into frequently used chunks and then doing the same. code is harder, there are frequently reused strings, but they change from technology to technology. overall there is far more entropy in computing than english on a character by character level, so designing a chording scheme that is more efficient and isn't tied too much to a specific domain is actually a really hard problem, especially once you consider that the effectiveness of a given scheme is not only a function of how well it fits the problem (how often the user is actually entering things the scheme was designed for) but also how well users are able to learn the vocabulary of chords and the dexterity to execute them quickly.