Jupytext solves this for me completely. It is an extension to jupyter code which can be turned on (globally or per-notebook, with additional configuration options) which automatically syncs the notebook to a file which can be checked into git and has nice diffs. It is a two-way binding, so editing the file will include those changes in jupyter, and if you check out a file in that format it can be converted into a jupyter notebook on your side easily as well.
But there is zero reward for showing replication results. Not novel enough, you won't get published. And if you're unable to replicate it then maybe you just did it wrong, or there was a small trick they were using in the code which they left out of the paper, etc.
I understand quite well the connection between static type systems and proofs, and how compilers work. As pointed out by another user here, an amazing amount of optimization can be done while maintaining the dynamic nature of the code and, in my opinion, while doing data analysis this is an absolute necessity.
As for static typing providing a proof of correctness, yes, many times I have wished that Python had better static analysis so that I didn't have to run my program only to get an error halfway through. On the other hand, when writing an experiment I rarely know at the start what the eventual design will look like. It is rarely worth setting up a fully expressive type system at the onset, so I wouldn't really get many of the correctness guarantees aside from existing types. My experience with mypy/PyCharm has demonstrated that a surprising amount of type inference can be done in dynamic languages, which allows me to catch most errors prior to runtime at this point.
While Swift the language might have support on Linux, last I used it (~ 8 months ago, when this initiative was announced) it was cumbersome at best. See the Swift for Linux initiative which, while being a fervent supporter of getting Swift working on Linux, admits right in the introduction that it is not great:
http://swift-linux.refi64.com/en/latest/
As mentioned there, even when I got the core language working I was smacked in the face with another of the core issues with Swift: the ecosystem is anemic, at best, on Linux. Almost all of the libraries are MacOS only.
While informal, I do not think his tone lacked civility.
I strongly prefer papers written in this style. Not only are they more enjoyable to read, but they are often easier to understand and more geniune as well. Papers written in a formal style often obscure the real motivation and instead provide a fancy-sounding retroactive justification. It makes the authors feel smarter, and I guess some readers feel smarter as well, but it belies the reality of research.
I don't think that was his motivation, I think his motivation was stated quite clearly in the abstract:
> The author's lone goal is to show that the entire field might have evolved a different direction if we had instead been obsessed with a slightly different acronym and slightly different result.
Julia does this. You can run the code and you get the output right next to it in an expandible dialog. You can write your while program this way, executing a line of code, tweaking it until it is correct. It can be quite nice. My one complaint is that VSCode doesn't have support for this, so it runs in Atom, and I find Atom to be quite slow and buggy.
The community of people using Swift for numerical computation essentially didn't exist prior to their announcement, and after their announcement it seems to only consist of the team developing the framework and Jeremey Howard.
Except it basically only runs on MacOS, which means that it doesn't have strong datacenter support, which means that it won't be used in any serious applications.
It's also not dynamic, which is almost a must-have for exploratory data analysis.
I will avoid a point-by-point rebuttal, mostly to avoid seeming too antagonistic, but Julia supports many of the other features on the list you provided, and (more importantly, for the case at hand) already has proven it's capability in the differentiable programming paradigm with Zygote.
Many of my relatives seem to have no interests or hobbies. I mean sure, they watch TV and movies, but it's not like they are deeply interested in them, they serve more as pastimes. They don't have anything they are actually passionate about.
In fact, there's always some inherent risk that the item you're buying is damaged in an unnoticeable way, even if it is new. What if your car seat has a manufacturing defect? What if it was dropped during shopping? What if the store attendant dropped it while sticking the shelves? What if it was purchased, opened, and then returned to the store? Even if the store has a policy of not putting open box items back on the shelf, there are people who will go to great lengths to make it look unopened.
All this stuff is possible, I don't think there practical risk to buying a used car seat is all that much higher. Besides, what if you drop it. Are you going to buy a new one, just to be sure it isn't damaged?
Because they don't make money directly from iMessage, they make money by selling the hardware, and the fact that iMessage only works on their hardware increases it's value and further locks you into their ecosystem.
No, I was saying that it is strange that the debit card is only free if you use it a few times. If you give me a debit card and I don't use it, what did it cost you? A few pennies for the plastic?
Reading the link, it seems that Jeremy Howard only tried out Swift because Swift for Tensorflow existed. I got the impression from your comment that using Swift for this purpose was somehow "in-the-air" at the time, and many people independently considered it, but I don't think this is true. My impression is quite the contrary - when they announced Tensorflow support for Swift, I think many people were surprised.