Jan Vitek

That's how I view it. I still use R for plotting and quick stats analyses but it is painful to do any real work. I recommend the article "Evaluating the Design of the R Language" [1] - it reads like a horror story. The memory usage and performance is abysmal, the OO features are a mess, and the semantics are very weird ("best effort semantics" is about as predictable as it sounds!). The lexical scoping is based on Scheme but has so many weird edge cases. It's a dumpster fire of a language, but it somehow works for its intended purpose. [1] http://janvitek.org/pubs/ecoop12.pdf

The subtyping system is fairly complicated, but in practice users only need to really think about situations where the LHS is a concrete type, since that's primarily what determines runtime semantics (not to say that there aren't situations where specificity really matters, but it's quite rare). That simplifies the mental model considerably and our users tend to find it relatively intuitive. For a formal discussion, the group at Northeastern has been doing great work in phrasing some of the Julia internals in more traditional PL language, including a formal subtyping model. That paper is at http://janvitek.org/pubs/oopsla18a.pdf

TL;DR - the authors of this paper (http://janvitek.org/pubs/toplas19.pdf) tried for 6 months to replicate the results of previous research that showed certain programming languages were associated with fewer defects. They could not replicate the results (or I guess only replicate very small differences in outcomes), and identified numerous statistical and methodological (is that a word?) issues with the previous results. What's really interesting for me is the in-depth discussion about why the previous results could not be replicated, and best practices for moving forward to achieve reproducible results in general with this kind of research.

The "Unreasonable Effectiveness of Multiple Dispatch" talk is a good example of how multiple dispatch is special in a good way, in that everything (should) work together as new types and functions are added to the ecosystem. However, this also means the scope of potential integration bugs encompasses the entire ecosystem. The Julia manual has a small section about special composibility pitfalls arising from multiple dispatch: https://docs.julialang.org/en/v1/manual/methods/#man-method-design-amb… As best as I can summarize it: Multiple dispatch is supposed to dispatch a function call to the implementation with the most "specific" call signature. This means that you must design your functions with an eye to what everyone else has implemented or might implement so whatever function gets called does the "right" thing, and also that your implementation doesn't block someone else from writing their own implementation specialized to other types. This requires some coordination across packages, as shown in one of the manual's examples. The rules defining type specificity (subtyping) are complicated, and I think not in the manual. They have been inferred by observation: http://janvitek.org/pubs/oopsla18a.pdf. To quote from that paper, "In many systems answering the question whether t1 <: t2 is an easy part of the development. It was certainly not our expectation, approaching Julia, that reverse engineering and formalizing the subtype relation would prove to be the…

Could this perhaps be it? https://janvitek.org/pubs/ecoop11.pdf

For example • … manages the retirement savings of 5.5 million users • … for a value of 23 billion Euros • … with a team of 30 developers over 7 years https://erwan.lemonnier.se/talks/pluto.html https://janvitek.org/talks/dls09.pdf

A lot can be said in favor of R, but "straightforward" is a debatable description. The semantics of R were never really designed, and were only recently "discovered", post hoc. See "Evaluating the Design of the R Language" (http://janvitek.org/pubs/ecoop12.pdf).

The day after I wrote this, the replication authors came out with their rebuttal rebuttal: http://janvitek.org/var/rebuttal-rebuttal.pdf

Another approach to automated generation of test cases is through a process of turning traces into tests. Valid uses of code already exist. These are in the application itself and for a library you can find published code that makes use of it. A recent paper [1] covers this subject and demonstrates in R achieving better code coverage than hand written tests and does so for a large portion of published libraries. I think this is a very interesting direction for automated test case generation. If you look at snapshot testing [2] it reminds me very much of that. [1] http://janvitek.org/pubs/issta18.pdf [2] https://blog.kentcdodds.com/effective-snapshot-testing-e0d1a2c28eca

The paper "Julia: Dynamism and Performance Reconciled by Design" [1] (work largely by Jan Vitek's group at North Eastern, with collaboration from Julia co-creators, myself included), has a really interesting section on multiple dispatch, comparing how different languages with support for it make use of it in practice. The takeaway is that Julia has a much higher "dispatch ratio" and "degree of dispatch" than other systems—it really does lean into multiple dispatch harder than any other language. As to why this is the case: in Julia, multiple dispatch is not opt-in, it's always-on, and it has no runtime cost, so there's no reason not to use it. Anecdotally, once you get used to using multiple dispatch everywhere, when you go back to a language without it, it feels like programming in a straight jacket. Double dispatch feels like kind of a hack, tbh, but it is easier to implement and would certainly be an improvement over Python's awkward `__add__` and `__radd__` methods. [1] https://janvitek.org/pubs/oopsla18b.pdf

I think all this chart shows is that Rust is the clear winner; it didn't even make the chart! (sarcasm) The huge grain of salt to take with this reanalysis is that this was of 423 projects total[1]. On top of that, this reanalysis isn't telling you about more modern languages that have the promise of "fewer bugs" because the original study data ends in 2014. The original paper featured 850 projects[2]. The original paper indicates they don't see any real potential threats to the accuracy of their information but I think it does include a heavy bias towards newer languages (which may be dragging them up) for a few reasons: 1. It completely ignores improvements in code editors, code completion, linters, and other pre-commit auditing tools. What in 1996 might have been "fixing RuntimeException because I called the wrong function name" is not going to be as common in modern times. This should tend to bias the results upwards as you go back in time. A counter-argument here is that more people are writing software than ever before, which is diluting the understanding required to properly write code, which could be offsetting these improvements. 2. It includes the languages' times from before their popularity, e.g.: Javascript "starts" in 1999. While this is no doubt true it could hardly be seen as a true "programming" language comparable to the others when it lived only within the browser sandbox. 3. Tying in with the above, they deal with multiple languages in use in a…

I would strongly advice against it. It seems like you are looking at a PhD like "the diploma to have" but not realizing what a PhD is in practice. Read a lot of what a PhD consist in: At least, expect to be lonely and work a whole lot of hours by yourself without much guidance or external motivation, you are becoming the expert during a PhD, so you will not find a lot of people that can help you when you have a problem. (I don't say that good and knowledgeable advisors do not exist! but they also have a lot to do in 24h a day!) IMO, nothing prevent you from studying after your work like if you are already a PhD student, give it a try: Take any advanced CS theory book or better, a Math book in your area of interest and work it out until you managed to do most of the advanced exercises. If you think this is not a healthy/sane life/work balance.. For a lot of people a PhD is not either. Take your time and be sure to understand everything in the book at its full extent. While you are doing this or after having done a couple of books, take high quality research papers in your field (lots of them are free), and try to understand them, implement them and try to reproduce their results. If you want a PhD in Deep Learning, do not expect that the PhD will consist in implementing a network, testing it, and start again. You may need to understand a lot of information theory, statistics, inference, math theory, etc. Also, for a lot of research level interesting ideas: implementing them…