goerz

Right. Zero based indexing makes zero sense, unless you explain the underlying technical reason, that it’s an offset relative to a memory pointer (spend a week teaching pointers first!).

It makes sense in certain context (and in languages like C that have a low-level mental model). For scientific computing at a higher level of abstraction where the mental model of a multidimensional array is a tensor, and not a memory offset location, zero-based indices really get in the way

We’re talking in a context of scientific software here.

> I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase.

You have to do that anyway, because you’ll have to connect the code you’re working on with the scientific paper describing it. When the code uses variable names too far removed from the mathematical symbols, you have to do make two steps: figure out how the words connect to symbols and then figure out the symbols. This will be especially difficult for the mathematician/scientist without a strong coding background: they’ll have much less friction reading code that matches the symbolic notation and Greek letters that they’re used to.

> The advantage of English words is that everyone knows them.

Not when it comes to “math” words.

> `Σλ∀φ` is a chore to read for me.

Right, but that’s because you have a different background. For me, `Σλ∀φ` is much easier to read and understand. More importantly, a symbolic notation is much denser, which allows to parse long expression that would be very hard to understand if they were written out in words.

Again, this is for the very specific context of highly mathematical/scientific software that Julia excels at and is primarily used for. In a more general context (when the software isn’t a direct representation of a scientific paper), I’m 100% on board with good, descriptive variable names

I strongly second the virtues of extending a standard US QWERTY layout to your specific needs. I’ve done a “ U.S. International - Scientific ” keyboard layout myself that aims more for German and math Unicode: https://michaelgoerz.net/notes/the-us-international-scientif...

Been using that for years in one form or another.

Yeah, I’d only cite it if it was a critical part of the methodology for a particular paper, or in a didactic field. It’s good for them to have a citable paper, though.

I don’t know what the problem is. Seems top notch to me.

So don’t mess up the indentation when you paste. Seriously, in my 15 years of using Python on a daily basis this hasn’t been a problem once.

There’s nothing that says you can’t have patches in calver, as e.g. `YY.MM.patch`. So you can definitely have an LTS calver release, or even back port new features. You just have to do it in the patch version, or adopt some other variation of the scheme, e.g.`YYYY.minor.patch` or `YY.MM.minor.patch`

What I seem to be missing from that page is their “future plans” for when/if current (2021) papers will be available through Sci-Hub. In its current state, the site is essentially defunct.

> This was 25 years ago

That makes sense. Sorry if I was a bit incredulous ;-) I've been publishing for about 10 years, so I'm only talking about the current situation. Things might have been quite different before academic publishing was all online, before arXiv, and before having a "personal website" was a thing. If the publishing agreements back in the day already had a clause allowing the author to privately redistribute their paper, I would assume that if you as the author can get the published PDF anywhere (from a former colleague that still has academic access, directly from the publisher, or potentially even from SciHub), you should be free to then forward it to others or put it on your personal website. IANAL, obviously, so don't quote me on whether it violates copyright to get your own papers off SciHub ;-)

You usually have institutional access. If not, I suppose you can ask the publisher to email you the pdf. Or you might be able to download it from the the submission website. I don’t understand: you really don’t have PDFs of your own papers? Did you leave academia and delete your data?

All journals I have ever published to (in theoretical physics) explicitly allow the authors to put the journal PDF of their article on their personal or institutional websites. They also allow to have a "reprint" (identical content to published version, but not the exact same PDF) to be on the arXiv. I'm not aware of any journals in the field that don't allow this. I'm sure they exist, but I would not consider them for publication.

> at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension

Sure, it’s worth considering…

> It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal

You just answered your own question on why it’s not necessarily a good idea ;-)

Apple added an App Store rule specifically to prohibit this, see the first FAQ at https://developer.apple.com/app-store/user-privacy-and-data-...

For editing notebooks in vim, I've created https://github.com/goerz/jupytext.vim. Note that this does not allow to run any cells, it just edits the inputs.

The motivation behind this was to have some basic interaction with existing ipynb files on a remote server without having to run the jupyter server (and set up port forwarding etc.) It's worth noting that the `jupytext.vim plugin is most useful if you're actually not running `jupytext` within jupyter; If you are, you could just directly open the .py or .md files linked to any .ipynb in your editor.

I've used `jupytext.vim` to edit existing notebooks and then run them through `jupyter nbconvert --to notebook --execute`. It's also great for refactoring: moving code from a notebook files into a module, between notebooks, or to create a new notebook as a variation of an existing one.

I think jupytext is already as close to "first-class" support as you're going to get. Personally, I'd be happy to see the project included with Jupyter, but you'll have to pester the Jupyter devs for that ;-)

Nice!

Why doesn’t GitHub Actions limit the environment variables it exposes to jobs/steps? The codecov step doesn’t need my GitHub or PyPI tokens! Environment variables should be opt-in for every step in the pipeline: I should have to explicitly list every environment variable I want to expose. This leak is as much on GitHub as it is on Codecov

Also (for less-technical audiences), I don't exactly dwell on the de-duplication. It's just "Git makes snapshots and puts them into .git in some efficient way. Don't worry about it. Or, if you want the details, read the Git SCM book."

It may depend on the background of who you're talking to. Programmers may be very comfortable with diffs, but non-programmers (in my case, physics graduate students) usually aren't. On the other hand, everybody is familiar with snapshots: even high school student will end up with "report_v1.docx", "report_v2.docx", etc, which are snapshots at the file level (and work reasonably well as long as you have a consistent scheme and don't need branches). I've also routinely seen less-technical people organize their research / paper writing by making a weekly snapshot of their work folder ("project-2020-04-1"). Telling these people that git basically does the same thing for them automatically with a tree-like "labeling scheme" that allows for branches tends to go over quite well, in my experience. For actually programmers, I'd be inclined to give them a more technical introduction to git's internals. I'd still point out that git stores compressed snapshots, not diffs (especially if they're older and may have previous SVN experience)

Yeah, it's annoying. But Black has so little configuration that I'm ok with hardcoding command-line parameters in my Makefile/tox.ini/precommit hooks (`--skip-string-normalization --line-length 79`)

You can still think of them as snapshots. Git just does compression on the entire folder of snapshots, including de-duplication of data that doesn't change between snapshots.

In fact, when I teach git to students, I don't even bother with the trees/blobs, which in my view are just an implementation detail. I just tell them to think of git zipping up their working directory together with some metadata (commit message, reference to parents), and putting that zip file into its own "compressed" storage inside the .git directory. That seems to be sufficient for a good mental model of how to work with git (independently of the git's somewhat baroque command line interface, which just takes getting used to)

It's also not ready yet, missing critical features like editable installs. Right now, you still need a shim setup.py. Until pyproject.toml can actually replace setupy.py, I see little incentive to start using it: It's just one more file to add. The one exception is if the package actually has build requirements, e.g. for Cython modules.

Yes, that’s exactly the idea

Oh, I see what you mean. But a signed commit doesn’t imply that the signer vouches for the code or it’s history (unless they say they do, but then you have to believe them that they reviewed the entire history). What it does do is to guarantee that after a commit is signed, nobody can come in and retroactively alter the history of the repo.

It's not a matter of trusting the signer. Every commit includes the hash of its parent, and thus the combined hashes of all its ancestors. Signing just the last commits signs the entire chain.

“Rejuvenating Fortran” would have been a better title ;-)

Ah, thanks! So it's just "has to hold for all values of t > 0, including for t = 1"

Can someone explain to me how Int[0,∞](t^{n+1} x^n e^{-tx} dx) = Int[0,∞](x^n e^{-x} dx)? That is, the last two equations of section 1.

Fortran predates C, so 1-based indexing has been “here” arguably longer than 0-based indexing. Most languages targeted at numerical computing use 1-based indexing because mathematics uses 1-based indexing in linear algebra. That seems like a huge benefit to me! C has 0-based indexing precisely because it doesn’t have genuine multi-dimensional arrays and has to use pointer arithmetics instead (which in my opinion makes it a very bad fit for scientific computing)

Sounds like you want jupytext