
An Empirical Study of Programmers’ Acquisition of New Programming Languages [pdf] - lainon
http://cs242.stanford.edu/assets/projects/2017/parastoo-gdietz44.pdf
======
wcrichton
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
And here I am, Saving after every change, regardless of the language.

~~~
bhaak
If you save after every change why don't you use an auto save feature?

~~~
dmacedo
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...

------
mlthoughts2018
> “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.

~~~
TeMPOraL
Got to ask, what makes you use this workflow? What is it about your work that
makes it more productive than more standard ones?

I get it to some extent; I'm a heavy Emacs user myself. But for instance, why
C-z / fg1 between shell and Emacs, instead of using compilation mode[0], or
having your shell in an Emacs buffer, via M-x shell, M-x ansi-term or M-x
eshell? It works well with non-GUI Emacs; in fact, that's how I do most of my
work when traveling (terminal Emacs via SSH to home desktop).

\--

[0] -
[https://www.gnu.org/software/emacs/manual/html_node/emacs/Co...](https://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-
Mode.html)

~~~
mlthoughts2018
I’ve always found the experience of using shell within Emacs to be poor. I
spawn a lot of shell tabs in my workflow as well. If I want anything to do
responsive compilation or testing, I’ll just have a separate tab open running
some conttest command.

I also find when I use tmux, I avoid splitting windows or panes. It’s always
just one singular, dumb window per each shell tab, and just multiple sessions.
I’ve tried and tried with it and the overhead of manipulating window placement
is just worse than flipping between shells and treat it like all possible
windows are always equal to the full shell window.

~~~
kbenson
I use tmux the exact same way. Partially this is because opening multiple
terminals is _trivial_ , and it allows all the normal sizing functions that
window managers have figured out over years (or that I specifically coded as
shortcuts into FVWM2).

Why would I want to use a shitty pseudo-window system inside of a real window
manager, when I can just use multiple terminals and connect to a tmux session
in each?

Given that I also do a lot of my development remotely, so it doesn't really
matter what computer I'm on as long as it has either PuTTY or OpenSSH on it,
and all it really takes is the remote system being set up initially with vim
(which generally exists on the remote system already), optionally with a
single .vimrc copied over, or for a more heavy environment a .vim directory
with a few pathogen plugins.

It _is_ a trade-off. There are some things that are somewhat harder to do in a
text environment (although it's generally just "harder", not nearly
impossible), but there's also quite a bit of versatility. I have quite
comfortably worked from a netbook for a month before. Smaller screen size and
keyboard was the only problem.

~~~
TeMPOraL
> _Why would I want to use a shitty pseudo-window system inside of a real
> window manager, when I can just use multiple terminals and connect to a tmux
> session in each?_

With my workflow, Emacs is _the window manager_. It's good at that, especially
in text mode.

While terminal emulation / alternatives in Emacs have some rough corners, your
all shell interactions are within Emacs buffers, which give powerful workflow
advantages if you want to refer to previous results, or if you want to do some
ad-hoc scripting.

~~~
kbenson
> Emacs is the window manager.

Yeah, I've tried that with vim windows. It wasn't to my liking.

> your all shell interactions are within Emacs buffers, which give powerful
> workflow advantages if you want to refer to previous results, or if you want
> to do some ad-hoc scripting.

I'm not sure I'm understanding the advantage you see. I use named tmux
sessions that survive beyond terminal closing that I reconnect to. I have
history for months in those. I can use two of those and have an editing window
and a window to see compile/test results. If it's a remote connection and the
network fails, I just reconnect and reattach the tmux session, and I'm in the
same position I was, with the exact same screen shown and history. I can move
from home to work with the same amount of easy as well.

Since I would run tmux anyways just for that capability, I'm not sure the
benefit I get out of folding both those windows into the editor, other than
harder to manage resizing, and harder to manager if I want to add or remove
windows temporarily.

I'm not sure what making the buffer part of the editor is gaining there
specifically, but I think there _is_ something that I'm not gleaning from how
you're explaining it. I'm just not sure it's enough to counteract the pain of
in-editor window management (for me).

------
Dowwie
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.

------
mikekchar
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
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).

------
i_feel_great
See. We can rewrite everything in Rust.

~~~
Dowwie
Only the parts that matter

