dual_basis

Why? Unless you check "don't ask again" it will always ask...

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 they rarely host the bad shit themselves, so it still is easily blockable.

Of course, agreed!

How?

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.

Wouldn't this argument also apply to cars?

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?

What a strange rule. Debit cards presumably only cost the bank money if you use them.

Banks are associated with much worse at the higher levels of the income bracket.

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.

That might explain why they chose it, but it doesn't give me (or anyone else who isn't familiar with Swift already) any reason to consider it.

s/especially/exclusively/

I like differentiable programming a lot, but can anyone explain the motivation for Swift as their language of choice for this? I assume it was simply because they wanted to get Chris Lattner, and Swift was his baby. Julia seems like a much better target for this, I wish they had just dedicated some money or resources to that. I don't have a problem with Swift's language design per-se (although Julia's dynamic nature really lends itself more naturally to the sort of problems you might be trying to solve using differential programming, in my opinion) but its cross-platform support is terrible. Why would you choose Mac's boutique language as the foundation of your new paradigm?

Not the person you originally asked, but I can share a relevant experience.

I definitely have concerns with the amount of data Google has about me and, in particular, the idea of Chrome monopolizing the browser landscape. As a result, a few months ago I tried switching to Firefox, complete with container tabs and scripts which removed Google analytics from everywhere. The difference in search results was very noticeable. Most notable was that my Google news feed (on my Android phone) and YouTube recommendations quickly became filled with generic junk, whereas before it was so relevant I would often find the answer to something I had been researching earlier mixed in with my news feed.

I ended up going back to Chrome, mostly due to battery issues with Firefox, however even if I hadn't switched back I think I would have voluntarily turned off all the anti-tracking stuff. It is a data privacy concern, and moreover I hate the idea of giving Google all this data, but the benefits for me were very palpable.

How do you stop the bots from upvoting? If you make people fill out a recaptcha every time to upvote they just won't bother.

Then that's not great, based on the way I (and, from observation, many others) use search results. I often middle-click (or control+click) several links which look promising, loading them in new tabs in the background. When I have a decent number, I then go visit the sites themselves.

In addition, the best Google searches result in finding the answer directly in the preview of the page from the search results. Unfortunately there's not a clear signal to Google which site preview provided the answer in this case, or even if none of them did and I just gave up searching.

In reality, I'm sure Google's determination of which site was relevant is much more sophisticated, likely involving some machine learning.

I see.

I can see some benefit to motion planning on the device if, for example, decisions are being made based on real-time data. For example, if there is a pressure sensor for the nozzle then the board could use this this realtime data to adjust it's motion.

If there's no realtime data being input then everything is simply a deterministic function of the gcode, and all of these aspects related to acceleration and jerk can be precomputed on your powerful multi-core desktop and "rolled into" the gcode.

I always thought that this was because taxi drivers wanted to appear, to their passenger, that they were trying to get them there as fast as possible.

My biggest complaint with ZFS is the lack of flexibility. If you setup two disks in a mirrored configuration, that's the end of it - those disks will be mirrored forever. If you get another drive and want to expand storage while still having redundancy, i.e. RAID5 type setup, you can't. You can increase storage with a pair of drives, by mirroring them first and then adding them to the zpool, but this is not an option configuration from a safety standpoint.

I loved the flexibility of BTRFS in this regard - you could change the duplication level at any point. BTRFS seemed to abstract the storage away beautifully - just give us your drives, any combination of sizes, tell us how many copies of your data you want to keep and we'll handle the rest. It wasn't perfect, but I loved this approach, and I feel like it could go even further, eg. calculate risk of failure probabilities and then just tell it how low you want your risk. If it can't do it with your current drive capacities it could tell you what it needs to accomplish it, and then rebalance the data once you add the drives. Got an SSD? Throw it in the pool and let it optimize for cacheing. I know bcachefs has that particular aspect covered, but there's a lot of other basic features that still need to be implemented.

I just want a USB serial port that accepts gcode.

From what I've heard, this is not reliable in the current implementations. If the computer goes to sleep, is under high load, or crashes this can result in a failed print. Of course you could build in more and more safeguards for this sort of thing (buffer the gcode, have some "emergency stop" movement which moves the head up and away from the print and decreases the temp of the hot end if there is a break in the stream of instructions) but this is a lot of additional effort when you could just as easily push all the gcode onto an SD card on the printer.

I think that they're just using Marlin, a lot of the work is done for them.

There is also much more advanced motion planning they could do with a little more power available.

But for 3D printing isn't the printer simply reading the instructions in the gcode? It's not doing any motion planning at all, that is all decided by the slicer.