dual_basis
Joined 8 years ago
Joined 8 years ago
How?
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.
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.
> 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.
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.
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?