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

121–130 of 197 posts

Re: Autocomplete as an Interface (2015)

#121

Post by eitland »

lgessler wrote: post #92
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 don't think there's anything inevitable about AbstractSingletonProxyFactoryBean. This absurd design pattern has its roots in Java's misguidedly restrictive approach to abstraction, which all but requires classes and inheritance to be the primary units of abstraction. More graceful abstractions are unergonomic or impossible since Java was not designed e.g. for higher order functions. The requirement that everything…

> ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.

Is it really that hard to create a Helpers class with static methods?

I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for

- the niceness of having a IDE that can almost replace pair programming

- an ecosystem were dependency resolution works

Re: Autocomplete as an Interface (2015)

#122

Post by eitland »

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…

Eh. Maybe not enterprise (it is extremely custom software for courts) but I was sold on the idea of DDD by someone who has to deal with one single word from the dictionary having 14 different meanings to the customer.

And since the wording is pretty much directly defined by laws and regulations you better get used to it since unlike in small businesses you cannot just argue with the product owner that these two mean the same.

Re: Autocomplete as an Interface (2015)

#123

Post by deckard1 »

seanmcdirmid wrote: post #117
bo1024 wrote: post #72

Earlier quoted context omitted.

It sounds like you're using autocomplete as a substitute for a tool you'd like, but doesn't exist.

Code completion (not auto complete) was always meant for discovery and never to help save on typing, at least in textual environments. The idea of immediately showing you what some symbol can do without using the mouse is very powerful.

ehhh. Only if your API is incredibly simple. You still have to roughly know that some operation exists and what that likely name is for the operation. Otherwise you're scrolling through a list of hundreds or even thousands of possible matches.

If you know you have an array and you know what you want to do with that array but don't know the name of the operation you want to do with that array, then completion as a form of discover sucks. No one is likely to stumble upon, say, JS's ".some()" method without having prior knowledge that this function exists and have it do exactly what they want.

Re: Autocomplete as an Interface (2015)

#124

Post by tlarkworthy »

eitland wrote: post #121
lgessler wrote: post #92

Earlier quoted context omitted.

I don't think there's anything inevitable about AbstractSingletonProxyFactoryBean. This absurd design pattern has its roots in Java's misguidedly restrictive approach to abstraction, which all but requires classes and inheritance to be the primary units of abstraction. More graceful abstractions are unergonomic or impossible since Java was not designed e.g. for higher order functions. The requirement that everything…

> ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity. Is it really that hard to create a Helpers class with static methods? I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for - the niceness of having a IDE that can almost replace pair programming - an ecosystem w…

> an ecosystem were dependency resolution works

My coffee just shot out my mouth.... What?

Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much).

I really like that nodejs can handle diamond dependancies.

sidenote: I do like the simplicity of Java code though too.

Re: Autocomplete as an Interface (2015)

#125

Post by eitland »

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…

Somewhat less serious suggestion, not aimed at OP, but this whole thread:

How about everyone with less than two years experience with both IDEs and editors stand back so we grown ups can sort this out ;-)

On a more serious note and as someone who has been on both sides of the fence:

How about we accept that people are different? Some people like Mac, some like Linux and some - gasp - enjoy their Windows desktop.

That said, and as someone who has extensive experience from both sides, I think that if people put the same effort into learning and configuring their IDE as they put in learning and configuring vim then that might very increase productivity a lot more than last ten years worship of vim.

(And: do learn a bit of vim. It comes in really handy sometimes, just don't fall for the idea that some people sell that you cannot become a good developer without using it all the time.)

Re: Autocomplete as an Interface (2015)

#126

Post by seanmcdirmid »

deckard1 wrote: post #123
seanmcdirmid wrote: post #117

Earlier quoted context omitted.

Code completion (not auto complete) was always meant for discovery and never to help save on typing, at least in textual environments. The idea of immediately showing you what some symbol can do without using the mouse is very powerful.

ehhh. Only if your API is incredibly simple. You still have to roughly know that some operation exists and what that likely name is for the operation. Otherwise you're scrolling through a list of hundreds or even thousands of possible matches. If you know you have an array and you know what you want to do with that array but don't know the name of the operation you want to do with that array, then completion as a for…

Yes, you still have to know kind of how it was named and kind of how it was used. It is just the rest of the details you can forget (or likewise, don't need to remember). It is really useful when you have to use libraries that are kind of similar but not exactly.

Anecdotally, I use Typescript and code completion is exactly how I discovered Javascript's "some" and "every" methods. It involved lots of scrolling because I didn't know it would be named like that, but based on the presence of other list comprehension methods I had a good suspicion that they were there somewhere...I still often mistakenly write LINQ-named "all" and "any", but the online type checking quickly snaps me out of it. Code completion can actually be improved to deal with these cases with more utility, by not only matching on the parts of the member's name, but a system could also match on synonyms to parts of what you typed as well (or document aka's in the interface that play no other role than hooking into code completion).

Re: Autocomplete as an Interface (2015)

#127

Post by eitland »

tlarkworthy wrote: post #124
eitland wrote: post #121

Earlier quoted context omitted.

> ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity. Is it really that hard to create a Helpers class with static methods? I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for - the niceness of having a IDE that can almost replace pair programming - an ecosystem w…

> an ecosystem were dependency resolution works My coffee just shot out my mouth.... What? Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much). I really like that nodejs can handle…

I think the real trick is avoiding trickery in the first place.

If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it.

Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%.

It is now upgraded, faster and easier to understand and upgrade :-)

Re: Autocomplete as an Interface (2015)

#128

Post by deckard1 »

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 errors, full -Wall and -pedantic.

After using an IDE for awhile, I noticed my ability to get things right diminished. I gave up knowing things for relying on technology.

One area I notice this the most is spelling. I used to be able to spell. Now I critically depend on browser or editor highlighting of errors, or throwing a word into Google to see what Google tells me. And it's not just new or complex words. It's words that I used to know how to spell. If all I had were pen and paper, I would be helpless.

Some will say technology frees you to memorize other more important things. But the downside is you give up agency. And very well may just become that much more of a replaceable cog in the machine.

Re: Autocomplete as an Interface (2015)

#129

Post by [deleted] »

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…

[deleted]

Re: Autocomplete as an Interface (2015)

#130

Post by eitland »

Stratoscope wrote: post #65

> I have 90 files open in emacs right now and I can find any particular one in five keystrokes. Imagine having 90 tabs open in Chrome—you could never find anything! The Quick Tabs extension gives you autocomplete for Chrome tab titles: https://chrome.google.com/webstore/detail/quick-tabs/jnjfein... Just type Ctrl+Q and you get a popup with IntelliJ-style autocomplete. Another trick for Chrome tabs (unrelated to autoc…

400 tabs in Firefox. No special plug-in. No problem.

And, to be fair I thought Chrome had copied the Awesomebar by now?

Post reply on HN