Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autocomplete as an Interface (2015)

benkuhn.net

Post reply on HN
Print view View original

191–197 of 197 posts

Re: Autocomplete as an Interface (2015)

#191

Post by cdo256 »

utxaa wrote: post #189
useful wrote: post #27

Autocomplete is the first step. Then you get linting, static analysis, autoformat on save, and code snippets. All built into your fancy IDE with plugins. You are super productive, you learn from its suggestions that you can quickly flip through, and your coworkers are happy that they only have to check your code for correctness and implementation, not style and edge cases.

this is like the self driving car myth. i just don't think computation extends this far. ie, a computer cannot do math in the sense of the https://en.wikipedia.org/wiki/Entscheidungsproblem

If you're referring to formal verification tools (which help programmers mathematically prove that their program has certain properties). Then it doesn't need to extend into all the edge cases. Usually if the machine tells you it can't create a proof you add more checks to your code or pick the properties so that they're easy to prove. There's no need for completeness.

If you're referring to anything your parent mentioned, those tools already exist.

Re: Autocomplete as an Interface (2015)

#192

Post by jcelerier »

cdo256 wrote: post #190
jcelerier wrote: post #136

Earlier quoted context omitted.

> I type while looking at the screen, you should try typing with closed eyes. after some time you see the code directly in your mind.

I tried this once. I can do it easily with natural language but it's much harder to do with code (even code you're familiar with). I think this is because so much of writing new code is back-and-forth: start writing loop, realize I need another variable, go back and initialize the variable, back to where I was, oh this should be brought out into a function, ah this function should is now getting quite large I need to…

> I tried this once. I can do it easily with natural language but it's much harder to do with code (even code you're familiar with).

hm, that's interesting. I generally know pretty well the code I want to write before writing it. The question is what is the fastest way to get it from mind to buffer.

Re: Autocomplete as an Interface (2015)

#193

Post by z3t4 »

utxaa wrote: post #182
z3t4 wrote: post #173

Earlier quoted context omitted.

Once a code base reaches a million lines of code it gets difficult to keep it all in your head, and even if the software has a nice architecture with module patterns or what not, just the sheer amount of different methods and functions will slow you down. Sure autocomplete will help, but the best productivity solution afaik is to keep the code base small :P

google how linux kernel developers work.

> A kernel developer usually contributes both code and documentation to the Linux kernel. As kernel developers become experts in their particular subsystem, they contribute to patch review on the subsystem mailing list. Eventually, they may become the maintainer of a particular driver.

This sounds good to me. I'm not qualified to judge the quality of the linux kernel, but judging by the adoption, many features, and hardware support, they must do something right.

Re: Autocomplete as an Interface (2015)

#194

Post by jodrellblank »

baddox wrote: post #112
OskarS wrote: post #20

You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type if (myVector->empty()) { fillVector(myVector); } autocomplete will pop up a window like 4 t…

>This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. I suppose this is really just a matter of opinion, but it seems strange to argue that autocomplete is bad because it can be so useful that you'll definitely want to use it. Sure, it's a separate argument whether "Factory" and "Bean" are useful, but long, verbose, meaningf…

attemptHydrationAtCurrentPriority

Without knowing anything about React or what Hydration is, I’m suspicious of this name - “AtCurrentPriority” doesn’t sound like useful information, everything should happen at current priority otherwise what does the concept of a “current” priority mean?

In a shell you don’t list files in the current directory with “ls —in-current-directory”, because the current directory is what you get if you don’t specify anything.

Similarly, in a language with exceptions and a library with error results, “attempt” is a non-description; everything is an attempt by default, the interesting things might be things which somehow can’t or mustn’t fail.

This smells like it ought to be “Hydrate” and then have a version which can be specified at some other priority if that’s needed.

Re: Autocomplete as an Interface (2015)

#195

Post by dr_baba »

cdo256 wrote: post #179
thedirt0115 wrote: post #77

Earlier quoted context omitted.

Ok, I'm curious! What might such a tool look like or do? Did you have something specific in mind?

I could imagine two tools: 1. A tool that parses the text and draws red underlines on all the errors, this exists but (at least for C++ in VS 2017) it is quite slow. 2. A tool that automatically populates and updates types of variables and functions. Both of these could be achieved by somehow decoupling the front-end (as in before semantic analysis) of compilers and making them output the AST in some standardized tre…

Doesn’t the Language Server Protocol already do this, just via JSON instead of XML? I believe at least some LSP backends (e.g. clangd) just reuse a compiler AST and feed the data to your editor?

Re: Autocomplete as an Interface (2015)

#196

Post by afarrell »

bhaak wrote: post #174
afarrell wrote: post #158

Earlier quoted context omitted.

Vim can be used to do that, but not by me. After 12 years of using vim through MIT and various software engineering jobs, I've accepted that it would take a person of my mental abilities waaaaaay too long to set up. Or, can you recommend a good book on vim package management and debugging?

In my experience, there are people that like building their development from the bottom up and others like going from top down. It's perfectly fine to get a full featured IDE. If you miss the vi stuff, most IDEs nowadays have pretty good vim emulations (and thanks to to neovim, many have even perfect vim emulations). Nevertheless, for an intro into vim plugin management, a good book is "Modern Vim by Drew Neil".

> "Modern Vim by Drew Neil"

I took a look at that on Amazon[1], but the reviews seem to indicate that it gives a surface-level walkthrough of some of the available plugins. I'd need something that gives me a mental model I can use for debugging.

[1] https://www.amazon.co.uk/dp/B07DFBWVMB/ref=dp-kindle-redirec...

Re: Autocomplete as an Interface (2015)

#197

Post by funcDropShadow »

deckard1 wrote: post #128
OskarS wrote: post #20

You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type if (myVector->empty()) { fillVector(myVector); } autocomplete will pop up a window like 4 t…

What's often missing from these discussions is the impact on human memory. Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on... I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler err…

> I gave up knowing things for relying on technology.

Perhaps, it is not so much giving up knowledge but filling the first-level cache with other stuff, like the larger picture of the software you are developing or the ever growing number of abstraction layers below the code you are writing. And whether that is good or bad thing is an interesting question. I am not aware, that it has an definite answer, yet.

Post reply on HN