Something that happens to me when I’m working with an api is that I’ll need to construct a

Foo

. To do that, I need a

Bar

, a

Baz

and a

Frob

, so then I have to figure out how to construct each of those. Maybe

Bar

is available from a local variable, I have a getter for a

Baz

, but I have to build the

Frob

out of some other bits I have. I had the idea of a tool that constructs various recipes for getting to your target type based on the local variables and functions you have in scope. Sort of a multi-stage autocomplete. Do any of you know if this is an idea that’s been explored?

the closest I can think of is haskell's hoogle search. wouldn't be surprised if jetbrains has some prior art in this area

I’m a big Hoogle user, hadn’t even made the connection.

I think you should take a look at tools like https://github.com/augustss/djinn

Thanks, that does look interesting

Java has the Guice framework and its notion of

Provider

. But using it only convinced me that tooling here is deeply counter-productive. Making it easy to construct nouns only digs you deeper into the Kingdom of Nouns.[1] Soon things suck just as much as before, except now your old approaches to manage the problem no longer work. No, the solution lies in the other direction, in treating huge graphs of objects as a code smell that indicates bad design. [1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

It's not clear to me what your asking. Could you provide a concrete example?

http://up.csail.mit.edu/other-pubs/sloppy-programming.pdf

The second interface is an extension to autocomplete, where the system replaces keywords in a text editor with syntactically correct code. This interface is aimed more at expert programmers using an integrated development environment (IDE). As an example of this interface, imagine that a programmer wants to add the next line of text from a stream to a list, using Java. A sloppy completion interface would let them enter "add line" and the system might suggest something like "lines.add(in.readLine())".

Maybe skip down to the “Quack Eclipse Plugin” heading.

So, given the code:

class Thing {

private Baz baz;
private String s;

Foo doStuff(Bar bar) {
   // what goes here
}

I’d want to synthesize:

Foo doStuff(Bar bar) {
          Frob frob = new Frob(s);
          return new Foo(bar, baz, frob);
    }

This reminds me a lot of typed holes in functional languages like Haskell, where you still write code, but place an underscore

_

where you want the compiler to tell you which type it expects. Details and example here: https://wiki.haskell.org/GHC/Typed_holes As far as I know all you get from Haskell at this point is the expected type and a list of types “in scope” at that point. Idris, I believe, is a language that takes this further and tries to suggest what code you’re likely to write, and also supports this with a feature called “interactive editing”. I haven’t used Idris, so I don’t know how good it is at inferring the correct type if it is not trivial and needs some indirection, as in your example.

Agreed Type holes offer something here, stefan would know better then me. But it always bottoms out at the developer understanding the primitives there directing towards a customer facing problem. The types in this example aren't personally telling me anything about the problem. If the types can be dropped in without any consideration, then i would argue we have a created a bad set of abstractions. Or maybe i should say, being able to know the range of types doesn't tell you how they should be constructed. If it does, then we just have pushed the problem downstream into "how should they be constructed".

That's what I like about the sloppy programming approach compared to the typed holes approach. You can create more than just expressions because you don't need a type hole, and you get the programmer's free-text query as an additional input to guide the search. "return new Foo(bar, baz, new Frob(s))" is the kind of result that even their initial algorithm could produce given a query like "return foo".

This also ties into discussions about type systems we had in other threads. To make up a slightly more specific example: if, say, you’re working on a graphics library and you implement a function to draw a rectangle, you'll likely want to pass in parameters that describe the bounds of the rectangle. On the lowest level, these could be four float values for x, y, width, and height. But on a higher level, you could also pass in two vectors: position and size; and these could be of the same type (vector) or of different types (point, dimensions). And on an even higher level you could just pass in a single parameter frame. API design and the chosen types and data structures will play a huge part in how well auto completion and similar tools can make useful suggestions for you.

@Justin Blank OO magnifies the issue, but I think the underlying problem is more fundamental: if you widen a road it adds to the incentive to buy more cars. When creating tools for the long term it's worth thinking about such secondary incentives. Tools are easily turned into externalities. I think the right place for tools is to make programming more accessible to newcomers. But they should be explicitly designed to be outgrown. Otherwise making a tool to support say functions with 10 arguments is just an invitation for people to create functions with 20 arguments. In particular, tools that solve pain points in today's mainstream stacks won't always be part of the 'future of programming' (i.e. escape the evolutionary dead end the mainstream finds itself in). Sometimes changing two things at once may give better results. But you may not be able to use such a solution at work.

can't believe I forgot this but you may also be interested in minikanren

I’m literally playing around with the idea in prolog and clojure’s

core.logic

..curious why you specifically mention miniKanren?

just throwing another current project in the ring - https://re-find.it/ is a project that uses Clojure's specs (predicate-based contracts, not types) and a set of input/output values to find possible function matches