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

151–160 of 197 posts

Re: Autocomplete as an Interface (2015)

#151

Post by ehnto »

gnulinux wrote: post #104
ehnto wrote: post #52

Earlier quoted context omitted.

> Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. You have it the wrong way around. Naming like that comes from the structure of the application, which just happens to benefit the ability for autocomplete tools to understand it. If you've ever worked on enterprise software, with hundre…

I disagree, there is nothing particularly different about "enterprise software" that requires a different naming scheme than other software. This is simply a cultural habit, and this cultural habit is supported by the fact that this same community uses IDEs that have good autocomplete feature. You can write enterprise software without naming your classes that long and be absolutely fine, and I argue this is not a tra…

Enterprise software gets a lot of cargo-culted software patterns thrown into it, for better or worse. That's why you end up with names like that. The software design is convoluted, not the naming convention. The word Factory in WidgetFactory represents a software structure, not just the fact that it makes widgets. You're probably right that it's a cultural thing to use all those patterns though, but not for nothing.

I disagree that there's nothing different about enterprise software, the needs are inherently different to a product-owner/single-purpose software platform. By enterprise software, I really mean enterprise frameworks that are used across many projects and many teams. Patterns are simply a shared language of concepts. The need for strict structure so anyone can work on it or extend it without messing the whole thing up or introducing new concepts or legacy code is what drives the patterns.

You could absolutely build super simple large scale software without all those concepts, but then you get yourself a boutique app that only your team is familiar with. Which is fine for a single product owner platform, not fine for a framework with hundreds of devs working on it who all need to collaborate without ever talking to eachother.

Re: Autocomplete as an Interface (2015)

#152

Post by gfunk911 »

kall wrote: post #119
intrepidhero wrote: post #83

Earlier quoted context omitted.

VB6 had a feature where if you typed a previously defined name with the incorrect case it would autocorrect it for you. I used to type my identifiers with purposely incorrect casing so that the autoformatter would confirm that I had selected the correct variable or method name. I really liked that feedback. Not that I'm saying that was a great workflow. But I liked the subtle feedback as I typed. I've also used autoc…

I rely on prettier (AST based JS+ formatter) in the same way. I intentionally add to little or too much space to get subtle feedback on if there is a syntax error in my (deeply nested) code.

I do the exact same thing with Prettier. I get a little spark of joy every time my code snaps back into place :)

Re: Autocomplete as an Interface (2015)

#153

Post by gravypod »

rohansingh wrote: post #118
gravypod wrote: post #15

I wish more engineers cared about auto complete. A lot of software people I know say "just use vim" or "just remember things" and I feel these view points really stifle progress. Just recently I've been trying to use Bazel for for a personal project. When you use gRPC you don't get any auto completions on generated code. I haven't been able to locate anyone who cares about this because they use some text editor confi…

Are you using gRPC with Go bindings? There is work underway for rules_go in Bazel to expose generated types like your gRPC and Protobuf classes. You can follow this issue for updates: https://github.com/bazelbuild/rules_go/issues/512

Unfortunately I'm using python, Java, node, and C. I don't know much go and I don't get many changes to use it at work.

Re: Autocomplete as an Interface (2015)

#154

Post by fbartho »

seanmcdirmid wrote: post #70
jasonlotito wrote: post #57

Earlier quoted context omitted.

> I find that the timing is actually worse That's fine. Amazingly, these things are customizable to fit everyones needs. Thinking there is only one way to do it is silly, but apparently a number of developers things autocomplete can be done only one way.

They aren’t really customizable that much. I don’t think there is a property in VS or VS Code to haggle with to reduce autocomplete timing to zero, and it still doesn’t deal with it being too intrusive to be used continuously. Each design decision has a cascading consequence, making customization very difficult.

Happily, there are some settings like that. https://code.visualstudio.com/docs/editor/intellisense

``` // Controls the delay in ms after which quick suggestions will show up. "editor.quickSuggestionsDelay": 10, ```

Re: Autocomplete as an Interface (2015)

#155

Post by aidenn0 »

totalperspectiv wrote: post #38

I wonder if there is a measurable difference between software written in a very basic text editor vs an IDE. Differences like naming conventions, name length, number of files etc. I've always thought that an IDE, while wildly useful in some scenarios, pushes/allows for unnecessarily complex design choices. Or maybe I'm just trying to justify why I use vim...

For me, I find that having a good autocomplete makes code easier to read because it makes long names easier to type correctly.

Compare "save-lisp-and-die" vs "s-l-a-d". The latter is much easier to type and the former much easeier to read.

Re: Autocomplete as an Interface (2015)

#156

Post by z3t4 »

scarface74 wrote: post #140
deckard1 wrote: post #128

Earlier quoted context omitted.

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…

When I first started, I spent all of my time writing C at my keyboard with few interruptions. Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc. Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposeful…

When where you the most productive?

Re: Autocomplete as an Interface (2015)

#157

Post by seanmcdirmid »

fbartho wrote: post #154
seanmcdirmid wrote: post #70

Earlier quoted context omitted.

They aren’t really customizable that much. I don’t think there is a property in VS or VS Code to haggle with to reduce autocomplete timing to zero, and it still doesn’t deal with it being too intrusive to be used continuously. Each design decision has a cascading consequence, making customization very difficult.

Happily, there are some settings like that. https://code.visualstudio.com/docs/editor/intellisense ``` // Controls the delay in ms after which quick suggestions will show up. "editor.quickSuggestionsDelay": 10, ```

Neat! I've actually never had a problem with the delay in VS Code, and 10ms is basically the way I like it anyways (immediate).

Some people might still be annoyed by the code completion menu placement, which isn't configurable (yet).

Re: Autocomplete as an Interface (2015)

#158

Post by afarrell »

bhaak wrote: post #30
gravypod wrote: post #15

I wish more engineers cared about auto complete. A lot of software people I know say "just use vim" or "just remember things" and I feel these view points really stifle progress. Just recently I've been trying to use Bazel for for a personal project. When you use gRPC you don't get any auto completions on generated code. I haven't been able to locate anyone who cares about this because they use some text editor confi…

> I wish more engineers cared about auto complete. A lot of software people I know say "just use vim" or "just remember things" and I feel these view points really stifle progress. They are not very well versed in vim if they don't know about the autocomplete capabilities of it. The most basic form is matching with ctrl-n in insert mode. http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-N This can be beefed up…

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?

Re: Autocomplete as an Interface (2015)

#159

Post by celeritascelery »

I am glad to see emacs mentioned. One of the cool things about it is that you can have completion your way. For example I made a package for when you are running shells in emacs it will send a tab character and then intercept the output. Then it displays it in an emacs pop up. Completely bypasses the issue of bash adding new prompts with every tab.

https://github.com/CeleritasCelery/emacs-native-shell-comple...

Re: Autocomplete as an Interface (2015)

#160

Post by scarface74 »

z3t4 wrote: post #156
scarface74 wrote: post #140

Earlier quoted context omitted.

When I first started, I spent all of my time writing C at my keyboard with few interruptions. Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc. Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposeful…

When where you the most productive?

It depends. Being able to do the entire stack yourself saves the communication overhead of working with a group of people.

But on the other hand, for the good of the company, it’s often good to sub optimize the individual for the good of the team. You usually don’t want only one person knowing the entire feature and while you will lose out on individual productivity, you can get features out sooner if you have more people working on it.

On a personal level, I love having not to wait on other departments/props to get my work done especially in a dev environment.

Post reply on HN