9 ms·

I met someone at a conference who was both a stenographer and a developer. Because the dictionaries which convert the keystrokes into words are just JSON, he c

I met someone at a conference who was both a stenographer and a developer. Because the dictionaries which convert the keystrokes into words are just JSON, he changed them to common commands/code snippets. Watching him code was mindblowing.

deleted 7y ago
[deleted]
rinchik 7y ago
This is awesome! learning to write in shorthand was in my bucket list, but this! This is way cooler. imagine writing code as fast as your thoughts are? Well, also a note: programming is not typing. it's 90% thinking. But at the end of the thought process, it just burns to turn your thoughts into working code ASAP! It would be so nice to streamline, optimize the process of the thought to code transfer. Until mind readers are invented, steno is a great solution
- Enginerrrd 7y ago
  >imagine writing code as fast as your thoughts are? I'm skeptical that typing is the bottleneck you think it is on the code-writing front.
  - buzzkillington 7y ago
    I'd go one step further and say that allowing you to type faster just makes your programs worse. >Why should I spend time implementing this logic as a function when I can just use macros to type it 5 times with 5 key strokes?
    - rinchik 7y ago
      Well, Mr. BuzzKillington(!), I’d disagree. I’d argue that fast thought to code ratio would give you wings! Surely you’ll type bugs in faster (valid point) but you’ll fix those also as fast! Overall development progress is incomparable.
      - Enginerrrd 7y ago
        I mean you do you man, but I've definitely spent an hour and a half on 1 line of code to make it fully vectorised instead of doing things the easy fast way iterating over the data and that code could run orders of magnitude faster than the fast way of coding. I remember once in undergrad we had a particularly gnarly computation problem to tackle. Some people's code ran as long as 40 minutes. Most were around the 10-15 minute mark. A few were in the 4-5 minute range. Mine ran in 50 seconds. No one else came even close. Now, I get that that's not always required. For a one off calculation, it makes no sense to spend 3 hours of developer time to save 1 hour. But if you have to run it 10, 100, 1000 times it starts to make a lot of sense. I can hack together a convoluted piece of shit pretty quick. No design doc, documentation, design elements that would give me flexibility or error checking. There are always compromises, but I just find it's extremely rare that my typing speed is the limiting factor. It always seems like spending a bit more time thinking about design saves me time in the end. Maybe you're John Von Neumann or something but like I said, I'm just pretty skeptical.
        rinchik 7y ago
        Haha “you do you man” - hilarious! Read my “note:” in original comment. My whole point is a better human vs IDE I/O throughput. Can’t imagine this improvement can be any bad? Process stays the same, some aspects get significant improvement, that’s it EDIT: also how many times in your career you had a problem where you had to make a significant and time consuming effort over that one line of code (other than hackathons, of course). With practically all high-level langs in modern collaborative environments readability is prioritized. “I should be able to read your code as a well written prose” - uncle Bob’s statement, is pretty much universal doctrine. Ability to type fast here is greatly underestimated
        buzzkillington 7y ago
        >With practically all high-level langs in modern collaborative environments readability is prioritized. Readability and verbosity are two different things. I can see how someone using Java would think that typing faster is better. But that's a reflection of poor language design choices rather than anything intrinsic to programming.
    - z3t4 7y ago
      Often its better to have 5 pieces of code that look alike, then to have a function that has 5 different cases. And the former will be easier to modify and delete.
      - buzzkillington 7y ago
        Not when you modify state in the same scope. You now have 5! (120) ways of introducing bugs, if you just wrote it as a function that doesn't modify global state you only have 5 ways of creating bugs.
  - dogma1138 7y ago
    If typing is the bottleneck you aren’t a programmer you are an assembly line worker.
  - alpaca128 7y ago
    Typing speed may not be a bottleneck, however reducing delays between the thought and the implementation can still make a difference. Strictly speaking I don't need to use Vim to write and edit my code and it doesn't impact my typing speed in the slightest, however it cuts delays when modifying code(moving hands to mouse, to arrow keys etc.) much shorter and makes the whole thing feel more direct. Although from my perspective I have my doubts if switching from something like Vim to a steno keyboard would be worth the time investment. For the usual text and many other tasks I can definitely get behind the idea, though.
pmoriarty 7y ago
Much of the speed of stenography comes from using macros, and macros should be available in any decent editor without needing the use of a steno keyboard. For example, both vim and emacs have snippet or template plugins (ex: yastnippet, snipmate, ultisnips, xptemplate, etc) that can be activated with a short keystroke and which then expand to whatever code or text the user desires. Then, depending on the features of the snippet/templating plugin in question lots of other advanced behavior (such as selecting items from a menu, activating sub-snippets/sub-templates, etc) can be activated. No need to use a steno keyboard for any of this.
- SuperPaintMan 7y ago
  There are other benefits to using a smaller chorded keyboard though, namely with RSI prevention and general comfort. That's kind of what I was going for with the QWERTY layout for Georgi. Rather then using chording for briefs and phonetic phrasing, it's just used for simple mapping with QMK. Makes for a compact and ergonomic board. Check out the layout I've linked below. Weirdly, though developed for Georgi the lightweight springs have found themselves back into Gergo and GergoPlex as users have reported it helping with their RSI flareups (compared to traditional mechs) [1] http://docs.gboards.ca/Unboxing-Georgi http://docs.gboards.ca/Unboxing-Georgi [2] https://www.gboards.ca/product/gergo https://www.gboards.ca/product/gergo
- deleted 7y ago
  [deleted]
- alpaca128 7y ago
  In Vim(and I assume Emacs too) it's also possible to just define keybindings for any sequence of inputs, allowing even mode changes inbetween and differentiating between different file formats. I used that for a couple common symbols in LaTeX' math mode, e.g. entering ;lra gets me a \leftrightarrow. But I wouldn't recommend that approach for multi-line snippets and more complex cases, the config will get unreadable otherwise.
deleted 7y ago
[deleted]
max_ 7y ago
What conference is this?
- jaredwiener 7y ago
  not in an official session, but this was the conference: https://2019.srccon.org/ https://2019.srccon.org/
rambojazz 7y ago
I would honestly love to see him code. Do you know if any video is available online?
- Groxx 7y ago
  Tho it's not the same person, there are some talks by the Open Steno / Plover people, e.g.: https://www.youtube.com/watch?v=Wpv-Qb-dB6g https://www.youtube.com/watch?v=Wpv-Qb-dB6g , e.g. at 6:30 or so (edit: also one on the bottom of the "about" page)
knowtheory 7y ago
Hey Jared, in fact, if you click into the video on the Open Steno page, the stenographer & developer you're talking about is Stan Sakai, who is involved in Open Steno: https://twitter.com/stanographer https://twitter.com/stanographer
- jaredwiener 7y ago
  Yes! That's him

deleted 7y ago

[deleted]

rinchik 7y ago

This is awesome! learning to write in shorthand was in my bucket list, but this! This is way cooler. imagine writing code as fast as your thoughts are? Well, also a note: programming is not typing. it's 90% thinking. But at the end of the thought process, it just burns to turn your thoughts into working code ASAP! It would be so nice to streamline, optimize the process of the thought to code transfer. Until mind readers are invented, steno is a great solution

Enginerrrd 7y ago
>imagine writing code as fast as your thoughts are? I'm skeptical that typing is the bottleneck you think it is on the code-writing front.
- buzzkillington 7y ago
  I'd go one step further and say that allowing you to type faster just makes your programs worse. >Why should I spend time implementing this logic as a function when I can just use macros to type it 5 times with 5 key strokes?
  - rinchik 7y ago
    Well, Mr. BuzzKillington(!), I’d disagree. I’d argue that fast thought to code ratio would give you wings! Surely you’ll type bugs in faster (valid point) but you’ll fix those also as fast! Overall development progress is incomparable.
    - Enginerrrd 7y ago
      I mean you do you man, but I've definitely spent an hour and a half on 1 line of code to make it fully vectorised instead of doing things the easy fast way iterating over the data and that code could run orders of magnitude faster than the fast way of coding. I remember once in undergrad we had a particularly gnarly computation problem to tackle. Some people's code ran as long as 40 minutes. Most were around the 10-15 minute mark. A few were in the 4-5 minute range. Mine ran in 50 seconds. No one else came even close. Now, I get that that's not always required. For a one off calculation, it makes no sense to spend 3 hours of developer time to save 1 hour. But if you have to run it 10, 100, 1000 times it starts to make a lot of sense. I can hack together a convoluted piece of shit pretty quick. No design doc, documentation, design elements that would give me flexibility or error checking. There are always compromises, but I just find it's extremely rare that my typing speed is the limiting factor. It always seems like spending a bit more time thinking about design saves me time in the end. Maybe you're John Von Neumann or something but like I said, I'm just pretty skeptical.
      - rinchik 7y ago
        Haha “you do you man” - hilarious! Read my “note:” in original comment. My whole point is a better human vs IDE I/O throughput. Can’t imagine this improvement can be any bad? Process stays the same, some aspects get significant improvement, that’s it EDIT: also how many times in your career you had a problem where you had to make a significant and time consuming effort over that one line of code (other than hackathons, of course). With practically all high-level langs in modern collaborative environments readability is prioritized. “I should be able to read your code as a well written prose” - uncle Bob’s statement, is pretty much universal doctrine. Ability to type fast here is greatly underestimated
        buzzkillington 7y ago
        >With practically all high-level langs in modern collaborative environments readability is prioritized. Readability and verbosity are two different things. I can see how someone using Java would think that typing faster is better. But that's a reflection of poor language design choices rather than anything intrinsic to programming.
  - z3t4 7y ago
    Often its better to have 5 pieces of code that look alike, then to have a function that has 5 different cases. And the former will be easier to modify and delete.
    - buzzkillington 7y ago
      Not when you modify state in the same scope. You now have 5! (120) ways of introducing bugs, if you just wrote it as a function that doesn't modify global state you only have 5 ways of creating bugs.
- dogma1138 7y ago
  If typing is the bottleneck you aren’t a programmer you are an assembly line worker.
- alpaca128 7y ago
  Typing speed may not be a bottleneck, however reducing delays between the thought and the implementation can still make a difference. Strictly speaking I don't need to use Vim to write and edit my code and it doesn't impact my typing speed in the slightest, however it cuts delays when modifying code(moving hands to mouse, to arrow keys etc.) much shorter and makes the whole thing feel more direct. Although from my perspective I have my doubts if switching from something like Vim to a steno keyboard would be worth the time investment. For the usual text and many other tasks I can definitely get behind the idea, though.

pmoriarty 7y ago

Much of the speed of stenography comes from using macros, and macros should be available in any decent editor without needing the use of a steno keyboard. For example, both vim and emacs have snippet or template plugins (ex: yastnippet, snipmate, ultisnips, xptemplate, etc) that can be activated with a short keystroke and which then expand to whatever code or text the user desires. Then, depending on the features of the snippet/templating plugin in question lots of other advanced behavior (such as selecting items from a menu, activating sub-snippets/sub-templates, etc) can be activated. No need to use a steno keyboard for any of this.

SuperPaintMan 7y ago
There are other benefits to using a smaller chorded keyboard though, namely with RSI prevention and general comfort. That's kind of what I was going for with the QWERTY layout for Georgi. Rather then using chording for briefs and phonetic phrasing, it's just used for simple mapping with QMK. Makes for a compact and ergonomic board. Check out the layout I've linked below. Weirdly, though developed for Georgi the lightweight springs have found themselves back into Gergo and GergoPlex as users have reported it helping with their RSI flareups (compared to traditional mechs) [1] http://docs.gboards.ca/Unboxing-Georgi http://docs.gboards.ca/Unboxing-Georgi [2] https://www.gboards.ca/product/gergo https://www.gboards.ca/product/gergo
deleted 7y ago
[deleted]
alpaca128 7y ago
In Vim(and I assume Emacs too) it's also possible to just define keybindings for any sequence of inputs, allowing even mode changes inbetween and differentiating between different file formats. I used that for a couple common symbols in LaTeX' math mode, e.g. entering ;lra gets me a \leftrightarrow. But I wouldn't recommend that approach for multi-line snippets and more complex cases, the config will get unreadable otherwise.

deleted 7y ago

[deleted]

max_ 7y ago

What conference is this?

jaredwiener 7y ago
not in an official session, but this was the conference: https://2019.srccon.org/ https://2019.srccon.org/

rambojazz 7y ago

I would honestly love to see him code. Do you know if any video is available online?

Groxx 7y ago
Tho it's not the same person, there are some talks by the Open Steno / Plover people, e.g.: https://www.youtube.com/watch?v=Wpv-Qb-dB6g https://www.youtube.com/watch?v=Wpv-Qb-dB6g , e.g. at 6:30 or so (edit: also one on the bottom of the "about" page)

knowtheory 7y ago

Hey Jared, in fact, if you click into the video on the Open Steno page, the stenographer & developer you're talking about is Stan Sakai, who is involved in Open Steno: https://twitter.com/stanographer https://twitter.com/stanographer

jaredwiener 7y ago
Yes! That's him