[krilnon]

The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust is a programming language, while this paper describes an editor/IDE enhancement to turn natural language style input into ASTs.

This suggests to me that the most anti-sloppy languages like Rust would benefit the most from sloppy input inference techniques. Has anyone been working on developer tools to make writing Rust code easier? (Lifetime management is the obvious new language feature to target.)

[1] http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin... (pdf), or less-detailed: http://groups.csail.mit.edu/uid/projects/keyword-commands/in...

[portmanteaufu]

> (Lifetime management is the obvious new language feature to target.)

If you haven't toyed with Rust since late summer when Lifetime elision[1] landed, it's very worth revisiting. That feature made writing out lifetime notations unnecessary in 87% of the standard library. It's made things a lot more pleasant. There's still plenty of room for IDEs and editors to help out, of course, but the language itself is making great strides in usability as it matures.

[1] https://github.com/rust-lang/rfcs/blob/704f0060176418659698e...

[krilnon]

Ah, great; thanks for pointing out that it has changed. The last time I looked at Rust in detail was mid-April, so I hadn't seen that.

[wycats]

As someone who wrote a lot of code not in the standard library, I championed this RFC pretty heavily. Part of the reason is that I noticed that with the lifetime elision rules, code using abstractions (as opposed to the implementation of abstractions) tends to use even fewer lifetime annotations.

Incidentally, the 87% number is a bit misleading. Before the Lifetime Elision RFC, a limited kind of elision was already allowed (when a function borrowed a value but didn't return a borrowed value). The 87% number was the number of lifetime annotations that were still required even with that limited rule that could be removed with the new rule. When taking all kinds of elision into consideration, the number in the standard library is closer to 95%. (many of the remaining cases in the standard library involve the implementation of collections)

In practice, that means that the vast, vast majority of borrowed references don't require explicit lifetime annotations, and that is pretty close to 100% in "application" code built on top of abstractions.

[seanmcdirmid]

Greg Little's work is usually in PL HCI, which is concerned primarily with languages that improve on usability, accessibility, lowering barriers for the common folk, and such. The other approach is to force one to eat their vegetables (because they are good for you), so to speak; we also call these bondage and discipline languages. Generally, languages of the latter style don't focus on tooling so much, since the accompanying culture is more of the style of "think heavily before you write anything" rather than "fool around in your IDE for awhile to find something that works." They often don't consider the IDE or IDE-related issues as an integral part of the language design.

I'm not sure if anyone has done much work to narrow this divide. There are some COQ IDEs out there now, but I'm not sure how effective they are in relieving cognitive burdens while programming.

[krilnon]

You're right to point out the cultural divide w.r.t. tooling. It just seems to me that when two different people come up with pretty identical names for something and focus an essay/paper on that name, then there's likely an opportunity for some sort of cross-pollination of ideas.

[seanmcdirmid]

One person's vice is another person's virtue; I'm not sure how that would create opportunities for collaboration :)

The irony of the situation is that languages like Rust and Haskell provide a lot of static type feedback that theoretically would make their IDEs very powerful. However, in order for that to really happen, IDE concerns have to be considered very early in the language design process. As a result, we see the tooling crowns going to languages like Dart, whose "type system" is basically designed to make tooling possible (and secondly, for the early detection of errors).

[larsberg]

Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c

I tried to revive as much information as I could from my days in Visual Studio, but if you have additional feedback, I'm sure he'd be very interested to hear it! Obvious caveats about it being a long-term goal, no immediate plans to tackle it, larsberg is on Servo so what does he know, etc. :-)

[seanmcdirmid]

Speaking out of complete ignorance of what Rust's situation actually is, I think the key is to have a gentle slope from "bad program" to "good program" that allows for the IDE to provide bits of feedback along the way to get to the "good program" state along with helping out with much of the mental computation that the programmer otherwise does in their head.

Rust's type system doesn't really seem to be there yet: there are just "wrong programs" and "right programs" with not much in between. Gradual typing on the other hand works very well here.