Show HN: CodeMatch: IDE autocomplete on overdrive | Hacker News Reader

Show HN: CodeMatch: IDE autocomplete on overdrive

languageinterfaces.com

102 pointsmoondistance63 comments

This is one of Java's biggest problems: people write tools instead of libraries. Getting the path to the Desktop should be achieved in some way other than hardcoding the word "Desktop" and the path separator in your application code; it should be a method on some generic "desktop environment configuration" object that's passed into the class that needs it.

There are a number of big problems with autogenerated code. One is that if you change your "how to get the path to the Desktop" algorithm, you have to manually change it in every place. This is hard to get right, so now your program is buggy and you have no way of knowing that you ever fixed it. Another problem is that the hard-coded solution is intrinsically inflexible; if the programmer had delegated to some other object, configuration could be passed into the class. It's not the "move all files out of this directory" class' job to know the details of where Windows, GNOME, KDE, and OS X keep the desktop!

One other nitpick is the flaky snippet that makes the for loop. Typing "for (File file : files) {" takes almost no time. But the snippet names the loop variable wrong ("elem"?), and correcting this takes more time than manually typing it correctly the first time. If you're going to be smart, be smart; look up the un-pluarlization in a dictionary and choose that. But don't choose a super-generic variable name, because now you've made the code of everyone that uses this tool less readable.

All in all, people seem to love shit like this, but it encourages horrible programming practices. Making it easy to write long, linear pieces of code is not a good thing. I think the opposite is what we really need: make it harder to type so that you spend more time thinking and creating a design that requires less code!

If you don't know how to access the "desktop environment configuration" object, how do you find it?

Snippet search integrated into the IDE is very useful. Yes, the snippets in the video aren't perfect. That isn't a big deal - those snippets will be modified/replaced.

My point is that you shouldn't need snippets; where you would use a snippet, write a library instead. Adding code to your application is the worst possible thing you can do when programming. Don't use tools that make this easy.

How would you respond to this? http://news.ycombinator.com/item?id=2905201

"Programmers would still need to search for methods to call. You can use CodeMatch to write snippets that call methods and CodeMatch can also auto-import libraries (or insert the classes/methods inline)."

http://news.ycombinator.com/item?id=2905254

Absolutely love:

  1. IDE plugin (Eclipse, Xcode + MSVS incoming)
  2. Community driven snippets
  3. Integrated into autocomplete

This approach is the trifecta of productivity for software developers.

I remember years ago finding some "overly smart" autocomplete hints from IntelliJ that surprised me, for example typing paths to files and having it automatically guess at the path given the execution context and that blew me away.

At some point all of those "try and be extra smart" rules fell out of favor and seemed to disappear and just get replaced by more robust/concrete type-inference inside the IDE. I understand why, trying to be TOO smart and getting it wrong is absolutely maddening and helps no one, but it was still nice to see.

These clippets remind me of a middle ground, where the tool is trying to be very smart, but also requiring you to fill in the part it can't concretely guess at (e.g. path variables in the demo video).

The other big win here is that since this is essentially search plus paramaterized clippets, there is no reason this cannot work for Python, Ruby, Go, JavaScript and anything else you would want.

The community aspects of building up the repo is just brilliant. Best of luck to this team, this looks like a hell of a nice job!

  4. version-controlled snippets so you can know if there are improvements / errors

add that, and we're golden. But stale copy/paste code is flat-out dangerous, and that's all this really is from a code standpoint, with a bit of magic and discovery. Not that I'm downplaying the tool - I think it looks really good. Just that using community-generated code is dangerous unless you either carefully curate it, or understand everything it does.

Copy/Paste as horrible I think is oversold.

I would never paste in a snippet of code from a bad programmer because the code would look ugly and wrong and it would be obvious.

So the risk is bad programmers copy/pasting from other bad programmers. Sounds like an argument against bad programmers, not copy/paste.

Not everything should be abstracted into a library. I think the example in their screencast is a good one.

Yes, if the snippet has a bug, you're copying that bug everywhere. But if it doesn't, it saves you from writing a potentially buggy implementation.

I believed for many years as a programmer the dogma against copy/paste. Now i use it, as I use any other tool, in a way that I find appropriate.

What do you think of the version of the code I posted at http://news.ycombinator.com/item?id=2904572? I originally wrote it in response to your comment, "Not everything should be abstracted into a library. I think the example in their screencast is a good one," but then I thought it might have wider interest.

But what if the code looks beautiful and right, but hides a rare bug that the designer doesn't know about?

I totally agree, it's over-sold. But any time you're using something you don't fully understand, you run risks. Being able to be informed of updates / problems would change the entire practice of re-using snippets, and integration into an IDE is the perfect way to do so. You, as a contributor, could even learn of problems / improvements that others have found.

"But what if the code looks beautiful and right, but hides a rare bug that the designer doesn't know about?"

All I'm saying is, in my experience, developing systems and apps for 10 years, the "rare bug" you talk about is just not a big enough problem to warrant that kind of caution.

Because the kind of code that you put in a snippet and reuse is the kind of "glue" or boilerplate code that is a solved problem.

Very good point Groxx, my own experience with this was looking for some snippets recently and Google ended up directing me to DZone Snippets[1] for and what I found were snippets from Java 1.3 to do the task that in Java 6 had been completely reworked with some of the new APIs and language features.

So you have a very good point, for longevity, that the snippets need to be versioned.

[1] http://snippets.dzone.com/

Thanks, versioning is really important. By default, when you create a snippet, it only appears in your search results. There is an option to submit a snippet to be included in the shared results. We're building a moderation system to handle those submissions. In the meantime, we're manually approving submissions to the shared repository. The moderation system will include versioning.

We're also building a feature to allow users to define groups and share snippets with groups.

Good to hear :) How are you planning on tracking where snippets are used? I personally liked an idea I saw once of 'tagging' snippets with their Gist URL in a comment above the code, but it was a fatally-crippled idea because no IDEs supported such things transparently.

As much of a hell as it will be to add / maintain, can I also request that they have version + library dependencies listed somewhere, somehow, so you automagically get the most-correct one? I realize I'm asking for a package management system, and I have yet to see one that isn't fugly, but I can dream, can't I? At the very least, I figure language-version is a necessity due to syntax changes.

This is actually already partially implemented. If you insert a snippet that includes a method/class (e.g. search for "screenshot"), a comment uniquely identifying the snippet is included in the inserted code. We currently aren't inserting these comments for the smaller snippets because we thought it would be annoying (but we could implement an option to enable it). It would be pretty easy (once versioning is up and running) to notify programmers when newer versions of the identified snippets are available.

I didn't listen to the audio on this video, so maybe I'm missing something.

Don't you think it would be better to write the code like this?

    source = windows_desktop_folder()
    for file in source.list_files_in_folder():
        file.move_to_folder(source.subfolder("Photos"))

Or in my pidgin Java:

    Path source = windowsDesktopFolder();
    for (Path file : source.listFiles()) {
        file.moveToFolder(source.subfolder("Photos"));
    }

It might take a little bit longer to write the code that way, but it seems to me that it would be a lot easier to read the code afterward when you have to debug it; and you could use the same search engine to search methods that you use to search snippets.

(There's also the issue that, however good your snippet library is, it will contain bugs, and changes in the outside world will require corresponding changes in the library. One example is that my code here could conceivably run on MacOS or Linux, while the snippeted code hardcodes backslashes and therefore cannot.)

There actually is no audio, so you didn't miss anything.

Makes sense to me. CodeMatch also supports method and class insertion (http://languageinterfaces.com/help). If you create and share a snippet, I bet it would get upvoted (within CodeMatch).

Edit: there's a special markup to add a method/class - click on the "Insert Formula" button when in the snippet submission form for instructions.

Sure, the example in the video isn't perfect. If you think you have a better way of doing things, you can always submit it as another snippet, and that's the whole point. The video isn't trying to promote the specific code snippets - it's trying to promote one way to find and integrate them.

I do think I have a better way of doing things: instead of writing snippets that people then copy and paste, write functions, methods, and modules that people can then simply call.

This results in software containing ten times less code, which makes it dramatically easier to fix, maintain, and extend, than a system built by copying and pasting code snippets.

Now, I am not going to claim that this is a new idea. Ada Byron, after all, invented the subroutine. What I am going to claim is that programming by pasting snippets together and editing them, which is not a new idea either, is a stupid idea. The idea is probably at least as old as the subroutine. We have something like 60 years of experience with programming by copy-and-paste. That's plenty of time to figure out that it's stupid. It's a bad idea. It makes your programs hard to understand and hard to change. We'll probably never stop doing it, because sometimes it's unavoidable. But having a search engine that makes it even easier to paste code snippets does not make pasting code snippets a better idea. It makes it a worse idea, because it means that you can screw yourself more quickly and thoroughly.

I want to see a case that you think is better written using pasted-together snippets of code instead of by calling subroutines. The burden of proof is not on me; I'm just explaining the conventional wisdom. It's on you if you want to show that the conventional wisdom is wrong.

I do think that a search engine for APIs would be useful, and that a lot of APIs suck.

Interesting point. Programmers would still need to search for methods to call.

You can use CodeMatch to write snippets that call methods and CodeMatch can also auto-import libraries (or insert the classes/methods inline).

Of course, this isn't featured in the video.

Adding the import statement is fine. Method auto-completion is something I'm not OK with; it encourages API bloat and overlyDescriptiveNamesThatJustMakeTheCodeHarderToRead.

I don't program Java, but I might also be OK with having a program add type names where necessary. For example, you type "foo = new Foo()" and the software will add "Foo " in front, making the line "Foo foo = new Foo()". But, programming in terms of concrete instances is To Be Avoided, so maybe default to an interface and allow the programmer to toggle between the interfaces Foo implements. It would have to be a measurable win, though; typing FooI is not that hard, after all.

I'm definitely not discouraging the use of tools to make managing boilerplate easy; but it's a very fine line, some boilerplate cannot be eliminated with clever library use (imports), but some can (finding the path to the Desktop). Once you have a super-cool boilerplate generation tool, it becomes more tempting to add a quick snippet than to fix the language or library deficiency that's pushing you in the direction of too much typing.

Sometimes it's good to imagine things taken to the extreme. Imagine that C didn't have a preprocessor but it did have an editor that had really good snippets. Instead of saying #define PI 3.14 in your math.h file, the snippet would just type 3.14 in for you whenever you said "insert pi". This would produce the same object code as the preprocessor, but without another extra piece of machinery to mess up your source code. What you type is what the compiler sees!

Turns out that this isn't good, because computers are really good at pushing symbols around, but humans aren't. So don't show the humans the details, show them the abstract and let the compiler push symbols around.

(I've always wondered why someone doesn't add a preprocessor to Java. See also: coffeescript / javascript.)

How does CodeMatch encourage "overlyDescriptiveNamesThatJustMakeTheCodeHarderToRead"? I don't think it does. Search results are not code snippets.

If you're suggesting that the tool isn't useful or to be encouraged (as you seem to suggest in earlier posts), I'm interested in better understanding your rationale.

As far as I can tell, you have only critiqued possible ways that CodeMatch could be used, not CodeMatch itself.

You asked what I thought about completing method names and I told you what I thought. Searching in the IDE may be useful. GHCI has has this kind of thing (integration with hoogle/hayoo) for a while, but I've never found it that useful. Programming is more than just "pick the first result for a one word query".

Well done on the tool.

The Java Overlords should take note: this is what the language should look like. It shouldn't take special software to be expressive.

Exactly my reaction. While I'm very impressed by the tool, my main impression was that the language should have constructs allowing one to as expressive as possible, at the appropriate level of abstraction.

I'd use this less to deal with a language's lack of expressiveness and more to deal with abstruse APIs. It would be very useful for httplib2 or SQLAlchemy, even though both are written in a pretty expressive language.

I'd especially be interested in creating snippets for my own proprietary APIs, which are typically move more quickly and are generally less documented that big, established public APIs.

I think this is a great use case. Let me know if there is anything I can do to help :)

Awesome! I think CodeMatch could be the keystone for a partially voice-controlled IDE. CodeMatch maps relatively simple strings (like "read files") to nice code snippets. The next step is to map simple voice commands (like "read files") to their string representation in CodeMatch. I'm excited :-)

Killer leverage there. Also: mobile (touchscreen UI) development.

Do you think there would be immediate interest? I have considered building a mobile development tool, but didn't think mobile dev. was popular. However, it might be of interest to amateur programmers who lack access to laptops/desktops. Would be easy to build :)

Hard to say: it hasn't had much of an opportunity to become popular, because it hasn't been a real option so far ;)

That said, my sense is similar to what yours sounds like -- the audience will remain small, just because it'll never be as fast, even after a tool like yours cuts down the entry time.

I'll ask around and try to generate some use cases or niches where mobile could take off, and get ahold of you if I do. I remember Paul G. talking about it a year or two ago, maybe if you can get ahold of him he could share his thoughts. Meanwhile -- nice work.

Turning off the autocomplete/intellisense/whatever is always the first thing I do when forced to use an IDE (as opposed to a text editor). I find the feature distracting and unhelpful.

Curious that I'm so opposed to autocomplete in text editors when I'm so attached to globbing in my shell. What's the difference?

Well the first thing is that the shell doesn't use pop-ups that hide my code. This is my #1 problem with "over helpful" editors - popups appear, unasked for, right on top of the code I'm looking at.

Secondly, the shell only helps me out when I ask it to. I have to press <TAB> to trigger the globbing. If the shell can't guess what I want, then I just get nothing - I have to press <TAB> a second time to ask it to give me a list to choose from.

I'm not sure what the equivalent would be with a programmer's editor. The <TAB> key is pretty important for indentation, but a Ctrl+KEY combo might be too clumsy. Where could the list of choices go where it would be both near to the cursor and not obscure nearby code?

You just increased average developer productivity tens of times. I can already see the haters hate this new easy way to "code by copy paste", but for people who just want to use code to get things done, i.e., all 100% of coders, including the haters, this is a revolutionary boon.

This is a very cool project, and I agree that it will increase average developers' productivity. I do fear, however, for maintainability of those developers' codebases. Programming by copy/paste is bad because making a change to functionality in the future requires making the change in all the places you copy/pasted to. This tool might actually not suffer too badly from that downside, because the snippets are small enough that you wouldn't break them out into a separate function anyway.

There's probably already a dozen different ways to do this with Emacs, with context sensitivity depending on how hard you try, what language you use, and if you're prepared to suffer CEDET.

See http://www.emacswiki.org/emacs/Yasnippet for one option, http://www.emacswiki.org/emacs/AutoComplete#toc2 for another, and various bolt-ons to Anything: http://www.emacswiki.org/emacs/Anything

The installation link should be selectable somewhere, i only find it in the image.

http://languageinterfaces.com/eclipsePlugin

Thanks, now fixed :)

  user:	     dougwightman
  created:   591 days ago

And this is your first comment, along with an awesome submission! Welcome to HN ;)

Great idea! It's a shame it's only available for Eclipse. I would definitely make use of this if it were available as an operating system level plugin for OS X, a la TextExpander.

Thanks! Xcode and MSVS plugins are in progress. Should be available this fall. This is just the first release :)

... and TextMate s'il vous plaît

Feel free to contact me if you need any help / info on VS integration, mail in profile. I don't work on the editor team, which is probably where the bulk of your work will be, but I know some people there so I can point in the general direction.

Thank you! We could definitely use help.

Is IntelliJ on the road map?

IntelliJ already has shared template libraries, along with in-place choice / definition of the variables. What it doesnt have is the search. I'm betting that gets added shortly.

sublimeText?

Yeah, I was excited until I saw it was for Eclipse.

I like this a lot, but I'm frustrated by not being able to browse the snippets online. Ideally this would have an online backend like StackOverflow where users could browse the "keywords => code snippet" relationship, make comments, vote, and make revisions. With an open API, people would create the IDE plugins for you. I know I'd happily contribute to a vim plugin.

Thanks, we will open the API. If you share your contact info I'll let you know when it's available.

Snippets will also soon be browsable online (early September) :)

I saw a demo for something like this at a PLDI conference a long time ago. I think it was someone at IBM Research. I'm not sure if this is it, but the Quake IDE extension looks similar: http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin...

Very interesting idea. I usually maintain a list of snippets that do very common processing and paste it myself.

I see CodeMatch as a nice interface to access template-ized snippets, such as those that come with TextMate. Is it more than that?

We think parameterized shortcuts will be the primary use case, but there are several other cases that we're also excited about. Code snippets can easily be shared (they are stored online) and code snippets are searchable (beyond memorized shortcuts, you can find snippets previously unknown to you).

Will you have an API? I'd love to see integration with github's editor :)

Yes, there is an API. I'll document it online this weekend :)

Wow. That's absolutely mental! ^_^

I don't think I would use it myself, I'm a Vim guy, but I can see it being a very useful tool. Good work!

I'm a vim user myself, but there's no reason this couldn't be made into a vim plugin.

This is a great idea, but it would be nice to have a page on the website with a clear license of the snippets.

Is how this works, and its limitations, explained in the audio track? Because some of us are deaf.

The video has no audio.

Thanks. I asked because there are responses about things not explicit in the video (like "community driven snippets").

funny how the titles of the snippets look just like applescript/hypertalk

cheers !! very promising.

Reply on news.ycombinator.com