babahoyo

For me the appeal is 3-fold

1) I can contribute to widely used packages like DataFrames and HypothesisTests. I had never made a git commit before this and my only "real" programming was CS 101 in Java. The fact that I could get up and running so easily contributing is a testament to the language's ease of use

2) I think its tough to predict your computational needs at the start of a project. Sure everything can be done in `lme` in R at the outset, but if you need some new bootstrapping procedure that a reviewer wants you might be left connecting some high performance code to an existing, large, R-based codebase. That's tough. I think Julia makes that "refactoring" (if you can call it that) easy.

3) Hopefully Julia will open a lot of doors for me in the future in my research career. I will be able to write interesting simulation procedures that are otherwise too unweildy for the comparison R or Stata economist.

If you are running a script over and over (or using small modules to do organize things) it will be very fast and easy to work with. The compilation is just for the first time a script is run, not every time.

It really isn't a barrier any more than, say, waiting for `library` commands in R.

Yeah i guess the UI isnt that bad. Performance > UI in many cases for me though. Hopefully responsiveness times are something people consider more in designing an interface.

Weird question, but why is there so much bad UI out there? Do you feel like you've failed as a field when commonly used applications like Gmail and adobe reader have such bad user experiences?

It's crazy that microsoft got sued for anti-trust because explorer dominated so much of the market, and now they are ceding space so google can do the same.

ah thanks! Yeah these are super interesting

wow that is pretty dystopian

I've been looking for blog posts and content about macOS UX design and testing. Because it really is stellar. I'm curious what kind of stuff the elementaryOS team is reading that informs their design choices. Any ideas where to look?

But the nice interactivity of it is only in RStudio iirc, which is a major selling point.

I'm worried about seeing a script that says

    df = read_csv(file)
    df <- df %>% mutate(log_income = log(income))
    # do manipulations in shiny
    Shiny(df)
    # click "transform" in the top right hand corner...

I think this is missing the forest for the trees. The audience for these tools is people who have never written in a text editor in their life! They literally might not even recognize that some fonts are fixed-width and not know what textedit is.

That is to say, emacs might be over-kill. But literate programming is a pretty powerful concept in general, and rmarkdown and Rstudio (along with simliar tools in Python, Julia, etc.) make this super easy, and I think its a great way to introduce people to programming.

Getting people to use Git is the fight worth having imo, but its still hard. I was talking to someone the other day who didn't like git because tough to have comments about the work: they didn't use code reviews on github to get consensus, just comments in the code.

Plus there is the whole data-management problem. Quilt, SQL connections, and DataDeps for Julia are good solutions, but there isn't a single one answer that we've coalesced behind.

These are all really tough problems. I'm actually really interested in MS's acquisition of github for this reason. Maybe they can put some money towards the obstacles that have prevented mass adoption of scripting and git.

Getting people to switch to R (or Julia) from excel is to balance two competing goals.

First, you need to establish that scripting is far superior to point-and-click interfaces via reproducibility and legibility. This is the fight worth having, as it gets to the core of what it means to do science and share results.

Second, you need to convince them that they don't have to sacrifice the tractability and ease of use of excel. Jupyter notebooks, for all their faults, really sell this idea well. But the first goal should dominate the second. Nteract and shiny are great, but I they are big tools that are difficult to teach beginners to code up. We shouldn't say "use R because you can still use point-and-click interfaces", we should argue against point-and-click interfaces all together in this context.

I also agree with the poster below that running a script again with a new parameter changed is super super easy, and you dont need a GUI to explore data like that.

I weirdly love reading about other people's workflow. This is really cool thanks for sharing.

One issue I have with literate programming is that its difficult enough to write code, now you have to worry about writing code in the middle of writing prose. For that reason I prefer to just have all my code output a bunch of latex files so I can separate the code-writing from the paper-writing. Which I guess is against the philosophy of literate programming as a whole...

How did you get around this? Do you share the same frustration that you are constantly being distracted by one or the other?