4 ms·

The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust

by krilnon 12y ago

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-programming.pdf http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin... (pdf), or less-detailed: http://groups.csail.mit.edu/uid/projects/keyword-commands/index.html http://groups.csail.mit.edu/uid/projects/keyword-commands/in...

portmanteaufu 12y ago
> (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/704f0060176418659698eb63642e2071b109e029/active/0000-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/704f0060176418659698e...
- krilnon 12y ago
  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 12y ago
    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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c 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. :-)

by krilnon 12y ago

portmanteaufu 12y ago

> (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/704f0060176418659698eb63642e2071b109e029/active/0000-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/704f0060176418659698e...

krilnon 12y ago
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 12y ago
  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 12y ago

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 12y ago
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 12y ago
  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 12y ago
    Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c 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. :-)