Comment by lelanthran

1 year ago

> The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect.

Just my personal experience, it's not about how fast I can get my ideas down in writing (whether code or not), it's about how often I am broken out of the flow when typing.

At one extreme, using your stats above of "10 finished lines of code per day", you could argue that using this keyboard (https://www.youtube.com/watch?v=9BnLbv6QYcA) should have no effect on your productivity, and yet no developer would make or support this argument.

Small frictions add up; there's a joelonsoftware post that I read a long time ago about this[1], and it stuck for 24 years!

The best editor/environment is the one that gets out of my way. One where I don't need to look things up on google. One in which I have already learned all the shortcuts, and don't need to relearn them to make the software useful.

Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing, and then look it up again in a few years when that extension is no longer supported. Same for Vim commands.

Using VS Code, or a full-fledged IDE[2] removes the whole command interface: I now need to remember dozens of key-chords, not a handful of verbs and a handful of nouns. I need to remember which menu, and which submenu needs to be clicked.

Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens!

The "keyboard maximalism" isn't about speed == productivity, IME. It's about "friction == disruption".

--------------------------------------------

[1] From https://www.joelonsoftware.com/2000/04/10/controlling-your-e...

> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don’t seem to care about the magnitude of the event, only the quality.

> And I started to learn that the days when I was happiest were the days with lots of small successes and few small frustrations.

[2] Which I use daily, btw. I'm not knocking the developers who use IDEs.

> Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use

And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.

> Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens!

No. It happens only because you're used to Emacs and Vim, and unused to an IDE.

> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up.

And those frustrations are rampant in the Emacs/Vim world. People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

By the time I've done my coding, project-wide refactoring, and looked up half of a project's code most Emacsers/Vimers are still stuck trying to find all references with a full-text search.

There's a reason VSCode's LSP took the world by storm

  • > And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.

    It's one command that implements autocomplete which gives you access to the entire system.

    > It happens only because you're used to Emacs and Vim,

    That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.

    > and unused to an IDE.

    Objectively not true, if you had read the entire comment.

    > People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

    I think you have a chip on your shoulder about this. You read my post as some sort of attack on IDEs so responded with an attack of your own.

    My point was about little frictions all adding up. Sure, there's a steep learning curve in learning a programmable editor, but you only climb that curve once.

    It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts for similar functionality in Jetbrains/Eclipse/Vs/VSCode/etc.

    I'm just explaining why needing to remember fewer things is the path of least resistance for me; whatever argument you are talking about involving signs of great programmers is beyond the scope of what I am saying.

    • > It's one command that implements

      And you know this command how? You discovered it how?

      > That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.

      Indeed. And now you complain about friction in IDEs because you refuse to learn IDEs to the same extent.

      > My point was about little frictions all adding up.

      Yes, yes they do. And I find there are significantly more frictions in Emacs and Vim than in a modern IDE. The only reason you don't see them is that you've already learned Emacs/Vim

      > It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts

      Wat. I don't even know what these random numbers mean, and where you got them from. And how we went from functionality and capabilities to navigation.

      > I'm just explaining why needing to remember fewer things

      Thing is, you don't remember "fewer things" with Emacs/Vim. You end up remembering about the same, or greater number of things on top of significantly worse functionality.

      Like you pretend that remembering dozens of various commands to type into `M-x` is somehow easier, and requires less memory than remembering the common shortcuts for common actions and falling back to Cmd+P(VS Code)/Cmd+Shift+A(Intelli J) to look up actions you rarely use.

      6 replies →

> Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing [...]

> removes the whole command interface

`C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs. VS Code (and many other Editors, like Sublime Text) has the same "keyboard only" usage possibility as Emacs.

I've switched from Emacs (after more than 20 years) to VS Code to Sublime Text and did not need to change my habits. And to be honest, Sublime Merge is what Magit always wanted to be, a useful combination of GUI (for the "easy stuff") and a textual interface for git.

  • > `C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs.

    I slightly disagree with this assertion. I upvoted you anyway because I think it's mostly correct for those who aren't full into Emacs :-)

    My reason for disagreement: `M-x` in Emacs gives you access to every single thing that the editor can do (like the function to move the point forward with `forward-char`). The `C-s-p` in VSCode doesn't give you the same.

    • As long as we're being pedantic: M-x only gives access to every single interactive function (which means every function which has the `(interactive)` statement). I can't speak as how to that relates to Microsoft VS Code's 'C-s-p' though.

      1 reply →