4 ms·

I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that wa

I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO. Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems. A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.

Izkata 7y ago
Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.
- liability 7y ago
  Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.
  - Izkata 7y ago
    To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.
- madhadron 7y ago
  You need a better completion system.
dang 7y ago
I don't think the argument has to do with speed of typing; that is a minor concern, since the bottleneck is thinking of what to type in the first place. The issue is the intelligibility of the resulting program. That probably sounds counterintuitive, because people always say that long explicit names make code more readable—but this is only true of code locally. It is not true of programs as a whole. Using long names makes programs longer, as does factoring out subsections into functions and naming those functions. A longer program is harder to understand than a shorter one, and the delta expands non-linearly as system size grows. There's a deep tradeoff here, much deeper than the popular discourse around software development has ever accounted for. You can see this come up in the OP where the author introduces functions (listAttachment and attachmentInfoLineToAttachmentId) into the example without including their definitions, which would probably double the size of the example. If you have a rich set of orthogonal, composable primitives, you can do powerful things in a line or two that would require 10x or even 100x more code in other environments. The tradeoff is that you have to actually learn the primitives to the extent that you become like a craftsman in a workshop whose tools are all at hand and who can reach for each one as needed without thinking. If you don't know the primitives, of course that line or two will be inscrutable.
- liability 7y ago
  IMHO CamelCase is the offender, not the length of the symbol. (CamelCase kills local readability, and therefore global as well) lisp-style-hyphenation is readable to me, even when long. If it helps the code read like prose, all the better.

Izkata 7y ago

Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.

liability 7y ago
Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.
- Izkata 7y ago
  To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.
madhadron 7y ago
You need a better completion system.

dang 7y ago

I don't think the argument has to do with speed of typing; that is a minor concern, since the bottleneck is thinking of what to type in the first place. The issue is the intelligibility of the resulting program. That probably sounds counterintuitive, because people always say that long explicit names make code more readable—but this is only true of code locally. It is not true of programs as a whole. Using long names makes programs longer, as does factoring out subsections into functions and naming those functions. A longer program is harder to understand than a shorter one, and the delta expands non-linearly as system size grows. There's a deep tradeoff here, much deeper than the popular discourse around software development has ever accounted for. You can see this come up in the OP where the author introduces functions (listAttachment and attachmentInfoLineToAttachmentId) into the example without including their definitions, which would probably double the size of the example. If you have a rich set of orthogonal, composable primitives, you can do powerful things in a line or two that would require 10x or even 100x more code in other environments. The tradeoff is that you have to actually learn the primitives to the extent that you become like a craftsman in a workshop whose tools are all at hand and who can reach for each one as needed without thinking. If you don't know the primitives, of course that line or two will be inscrutable.

liability 7y ago
IMHO CamelCase is the offender, not the length of the symbol. (CamelCase kills local readability, and therefore global as well) lisp-style-hyphenation is readable to me, even when long. If it helps the code read like prose, all the better.