10 ms·

An Empirical Study of Programmers’ Acquisition of New Programming Languages [pdf]

88 points by lainon 8y ago

wcrichton 8y ago
For reference, this was a course project done in my class at Stanford (CS 242: Programming Languages) last fall, not a peer-reviewed publication. Overall a great project. The title is a bit general, but the goal was to identify what resources people found most useful when learning Rust and why. My favorite bit: > Participant behavior indicates that they found the in-line Rust Enhanced compiler errors that showed upon saving to be quite useful. Participants were not told about this feature, and only discovered it, on average, 1058 seconds (17 minutes, 38 seconds) into the task. However, after finding the Rust Enhanced compiler error feature, participants began saving every 30.6 seconds, on average, with an average of 24.8 total saves per person.
- cuddlecake 8y ago
  And here I am, Saving after every change, regardless of the language.
  - bhaak 8y ago
    If you save after every change why don't you use an auto save feature?
    - cuddlecake 8y ago
      Touché. Will check if VSCode has such a feature.
    - dmacedo 8y ago
      I do the same as parent comment. I had previously automated it; from simple timers, to every X seconds of inactivity; and in my experience with it, the automation took away time when some editor/compiler stops your flow (errors out/fatally because you haven't completed your current typing), or more importantly, that setup started either colliding with the key press save muscle memory (leading to some frustration when the editor just paused slightly for analysis twice) or slowly removing that muscle memory when working with other editors/setup that didn't have the feature enabled. I've since turned back (ages ago) and prefer this mental trigger to save and check for compilation/analysis at a pause in the flow. I really feel that works best, I'm sure the automatic save will work for others...
- jackconnor 8y ago
  I do Angular and I 100% agree, as I keep all compiler error outputs on for every save, and you find/squash a trillion bugs before they can turn into anything bad.
mikekchar 8y ago
Have not read this yet, but I'm very excited to find some time to do so. However, it seems that this does not reference any work done in natural language acquisition. I assume because the study authors are not conversant in the field. I'd love to know if anybody has seen any work that does relate the two.
- kbenson 8y ago
  I suspect if you dig into the origins of Perl, you'll find some interesting stuff. If not on purpose, as a case study of what happens when a linguist makes a language (and what he thinks worked and what didn't).
mlthoughts2018 8y ago
> “Given the positive sentiments towards in-line compiler errors and the lowered work-flow overhead resulting from removing the requirement of compiling within the shell, we recommend language developers create packages to make compiler mes- sages accessible in-line. This is consistent with prior work suggesting that the location of error messages and their struc- ture is critical [8].” Ugh, this type of result is so depressing to me. I am a “young” developer (early thirties, most experience with modern C, Python and Haskell). I just want to work in the shell! Stop foisting shitty UI tools on me to code with. They are not good. They just aren’t. I just want a shell, non-window mode Emacs, and command line search tools. My workflow is read read read type type type ctrl-z from Emacs to the shell run run run fg 1 back to Emacs. Always use git grep and ag to find code, never ever use “jump to definition” features not even in huge codebases (it’s just too slow mentally to rely on that context switch instead of ctrl-z git grep ... emacs -nw ...). The absolute most I’ll tolerate is syntax highlighting. The idea of compiler errors popping up in my editor with little Xs or squiggly underlines like a MS Word doc makes me throw up a little in my mouth. Gross. Every single time I’ve invested effort to become a proficient user of these types of tools, like intellij stuff and sublime and VS Code, it just kills productivity and I go right back to Emacs + shell programs.
- burntsushi 8y ago
  I work somewhat similarish to you (or at least, closer to you than the environment suggested in the OP), but I really don't understand why you're so disturbed. Don't use tools you don't want to use.
  - mlthoughts2018 8y ago
    The reason it bugs me is that popularity drives what will be supported by companies. I used to have plenty of linux and Emacs support from official helpdesk channels. In my last several jobs, not at all. At my current job, even though we rely heavily on linux servers and there’s a strong minority of Emacs users, the company (over 300 engineers) mandated that all support for configuring our in-house build tooling and monorepo tooling will be 100% Sublime on Mac, no support of any kind for Emacs. In one company, the primary language was Scala, and one of the primary Emacs tools for Scala is Ensime. But the company had its own bizarrely wrapped version of sbt running inside of pants tasks, so without explicit support from IT, it was not possible for a developer to use Emacs+Ensime for that Scala codebase. I am perfectly happy for people who use these UI-heavy tools productively. But the marketing shtick attempts to raise it in popularity and promote it, like this very paper’s recommendation, seem harmful to me. Code tooling should be extremely fractured, bespoke and customized, by its very nature, and that should be embraced and supported. Instead it seems like PR battles and a rise of (IMO) ineffective proprietary tooling.
i_feel_great 8y ago
See. We can rewrite everything in Rust.
- Dowwie 8y ago
  Only the parts that matter
Dowwie 8y ago
No mention of Mozilla IRC?! If it weren't for the seasoned, patient Rust evangelists helping in #rust-beginners, I probably wouldn't be using Rust full time right now.

88 points by lainon 8y ago

For reference, this was a course project done in my class at Stanford (CS 242: Programming Languages) last fall, not a peer-reviewed publication. Overall a great project. The title is a bit general, but the goal was to identify what resources people found most useful when learning Rust and why. My favorite bit: > Participant behavior indicates that they found the in-line Rust Enhanced compiler errors that showed upon saving to be quite useful. Participants were not told about this feature, and only discovered it, on average, 1058 seconds (17 minutes, 38 seconds) into the task. However, after finding the Rust Enhanced compiler error feature, participants began saving every 30.6 seconds, on average, with an average of 24.8 total saves per person.

cuddlecake 8y ago
And here I am, Saving after every change, regardless of the language.
- bhaak 8y ago
  If you save after every change why don't you use an auto save feature?
  - cuddlecake 8y ago
    Touché. Will check if VSCode has such a feature.
  - dmacedo 8y ago
    I do the same as parent comment. I had previously automated it; from simple timers, to every X seconds of inactivity; and in my experience with it, the automation took away time when some editor/compiler stops your flow (errors out/fatally because you haven't completed your current typing), or more importantly, that setup started either colliding with the key press save muscle memory (leading to some frustration when the editor just paused slightly for analysis twice) or slowly removing that muscle memory when working with other editors/setup that didn't have the feature enabled. I've since turned back (ages ago) and prefer this mental trigger to save and check for compilation/analysis at a pause in the flow. I really feel that works best, I'm sure the automatic save will work for others...
jackconnor 8y ago
I do Angular and I 100% agree, as I keep all compiler error outputs on for every save, and you find/squash a trillion bugs before they can turn into anything bad.

mikekchar 8y ago

Have not read this yet, but I'm very excited to find some time to do so. However, it seems that this does not reference any work done in natural language acquisition. I assume because the study authors are not conversant in the field. I'd love to know if anybody has seen any work that does relate the two.

kbenson 8y ago
I suspect if you dig into the origins of Perl, you'll find some interesting stuff. If not on purpose, as a case study of what happens when a linguist makes a language (and what he thinks worked and what didn't).

mlthoughts2018 8y ago

> “Given the positive sentiments towards in-line compiler errors and the lowered work-flow overhead resulting from removing the requirement of compiling within the shell, we recommend language developers create packages to make compiler mes- sages accessible in-line. This is consistent with prior work suggesting that the location of error messages and their struc- ture is critical [8].” Ugh, this type of result is so depressing to me. I am a “young” developer (early thirties, most experience with modern C, Python and Haskell). I just want to work in the shell! Stop foisting shitty UI tools on me to code with. They are not good. They just aren’t. I just want a shell, non-window mode Emacs, and command line search tools. My workflow is read read read type type type ctrl-z from Emacs to the shell run run run fg 1 back to Emacs. Always use git grep and ag to find code, never ever use “jump to definition” features not even in huge codebases (it’s just too slow mentally to rely on that context switch instead of ctrl-z git grep ... emacs -nw ...). The absolute most I’ll tolerate is syntax highlighting. The idea of compiler errors popping up in my editor with little Xs or squiggly underlines like a MS Word doc makes me throw up a little in my mouth. Gross. Every single time I’ve invested effort to become a proficient user of these types of tools, like intellij stuff and sublime and VS Code, it just kills productivity and I go right back to Emacs + shell programs.

burntsushi 8y ago
I work somewhat similarish to you (or at least, closer to you than the environment suggested in the OP), but I really don't understand why you're so disturbed. Don't use tools you don't want to use.
- mlthoughts2018 8y ago
  The reason it bugs me is that popularity drives what will be supported by companies. I used to have plenty of linux and Emacs support from official helpdesk channels. In my last several jobs, not at all. At my current job, even though we rely heavily on linux servers and there’s a strong minority of Emacs users, the company (over 300 engineers) mandated that all support for configuring our in-house build tooling and monorepo tooling will be 100% Sublime on Mac, no support of any kind for Emacs. In one company, the primary language was Scala, and one of the primary Emacs tools for Scala is Ensime. But the company had its own bizarrely wrapped version of sbt running inside of pants tasks, so without explicit support from IT, it was not possible for a developer to use Emacs+Ensime for that Scala codebase. I am perfectly happy for people who use these UI-heavy tools productively. But the marketing shtick attempts to raise it in popularity and promote it, like this very paper’s recommendation, seem harmful to me. Code tooling should be extremely fractured, bespoke and customized, by its very nature, and that should be embraced and supported. Instead it seems like PR battles and a rise of (IMO) ineffective proprietary tooling.

i_feel_great 8y ago

See. We can rewrite everything in Rust.

Dowwie 8y ago
Only the parts that matter

Dowwie 8y ago

No mention of Mozilla IRC?! If it weren't for the seasoned, patient Rust evangelists helping in #rust-beginners, I probably wouldn't be using Rust full time right now.