bow_

My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up"

Those aren't necessarily oppposing points.

NixOS is a declarative distro. It also happens to come with some defaults that, I assume, caters to the commonly expected use case (and maybe has some historical roots as well).

NixOS is not a minimal, build-from-scratch distro. It's more opinionated than e.g. Arch. For example, it ships with firewall turned on by default (https://nixos.wiki/wiki/Firewall). Another example: the default list of packages is somehow Perl, rsync, and strace (https://search.nixos.org/options?channel=26.05&query=default...). Blanking this default to an empty list is IME harmless.

The declarative nature is probably the subtext the author is trying to convey: what are the things one can do to disable these defaults, to reach a very minimal system (ISO really) that one can then build as one wishes.

Right ~ fair enough. I should have clarified I meant Debian stable (and by extension all other non-rolling release distros).

My own view: rolling release distros gets less in my way than distros like Debian. They allow me to install anything I want, as close as possible to upstream.

Not saying one is better than the other, just remarking that it's interesting to see 'getting in the way' meaning completely opposite things for different people :).

Right. Because only laid-off employees can cause such a damage of course (/s).

This is a twisted way to look at the risk.

Disgruntled employees have more reason to wreak havoc. All the more reason they should be treated as humanely as possible in a difficult period that in most cases is inflicted by the company itself.

I have been out of the field for some time, so I am not sure how much BLAST is used these days.

Therer was a time when BLAST-ing a DNA and protein sequence you have is like doing a Google search on it: it simply tells you where the sequence might come from. This is useful especially when your research is to figure out what that specific sequence is doing. It won't give you the answer immediately (otherwise why bother doing the research at all), but it certainly gives context: sequence similarity often hints at similar / related functions.

As an analogy: imagine if StackOverflow is suddenly down and you don't know *if* it's going to be up again.

Bit of an aside, I found this bit from https://hackclub.com/clubs/ interesting:

in the Hack Club Slack (Discord-style online groupchat), you'll find a group of 27,253+ fabulous ...

See, in my head Slack comes first before Discord. It was released, after all, 2 years prior. My mental shortcut for Discord is that it's like Slack but for games so it has better audio support. But here it's the other way around.

It's ok ~ perhaps the on-ramp path is Discord -> Slack -> IRC :).

Seriously though, this is really impressive. Not just flashy UIs, they actually have an intro to Assembly: https://github.com/hackclub/some-assembly-required

Kudos to these teenagers.

I can second AsciiDoc. It hits the sweet spot between Markdown (arguably more suited for short-ish content) and LaTeX (full-blown academic papers with citations, formulas, etc.).

Have been using AsciiDoc for the past few years and loving it, only falling back to Markdown on places where AsciiDoc is not (yet?) available. GitHub and GitLab, for example, supports rendering AsciiDoc. PyPI unfortunately has not supported it, but more seem to be looking into it [1], which is great.

--- [1] https://github.com/pypa/readme_renderer/issues/205

GSoC is awesome and I'm happy to see it's still running.

The experience I got as a student in 2012 was invaluable for my career in tech ~ more so since I did not formally study CS. It introduced me to so much: a lot of the programming itself, collaborating with fellow developers.

I spent one year preparing for it, and man seeing my proposal accepted was one of the best feelings I have ever experienced (much better than when I graduated, even). A close second is knowing that I actually was helping people with my code (I still keep the emails where people sent me questions about the library API I was developing).

I hope this year's (and future) batches of students get to experience the same (if not more) highs :).

But the real question is why they don't do the same for tax evasion?

Who says they don't?

If I had to guess, I would say the magnitude of the problem is just more complex. The tax system is more complicated and impacts more people.

They did attempt to change the law to give the tax agency more similar powers[1]. Last I checked, it was rejected due to public outcry[2]. I do not expect this to be the last attempt.

--

[1] https://kammeradvokaten.dk/nyheder/nyt-lovforslag-kunstig-in...

[2] https://pro.ing.dk/datatech/artikel/efter-massiv-kritik-mini...

It's neat ~ could have used checks in-between to ensure e.g. `$(go env GOBIN)` is not empty.

For something more comprehensive (of course with a larger install size) and the possibility of handling not just Go, I have had good experiences with asdf [1].

[1] https://asdf-vm.com/

Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation.

This was my goal anyway: implement Lox differently. Off the top of my head:

* I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching. * I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.

I didn't worry because of Java's perceived lack of 'excitement'.

Just that I am more familiar with other languages and I worried I'd get lost trying to understand Java and not digest the material properly. I tend to fall down rabbit holes sometimes ...

If anything, this has been another way for me to be more acquainted with Java, which I am happy for :).

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with).

Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one implementation).

Boy was I glad I did.

Writing is superb, end-of-chapter challenges are instructive, code samples are meticulously and beautifully done. Here and there I also encountered references to other languages (e.g. had a brief detour to Lua internals [1], thanks to a side note), which I have enjoyed too.

Went through the first half twice: first using Java as it is written and then secondly implemented the interpreter in Rust (my initial fear turned out to be unfounded). Currently going through the second half.

So if you're reading this, thank you, Bob :).

[1] https://www.lua.org/doc/jucs05.pdf

Introducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1].

The introduction of the RFC [2] also still mentions `false` is of type bool:

null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.

But why call it bool if `true` is not a standalone type too?

[1] https://docs.python.org/3/library/typing.html#typing.Literal

[2] https://wiki.php.net/rfc/null-false-standalone-types

Here I disagree. HTTPS gives guarantee to visitors of the site that they can trust the information being served to them.

A malicious actor hijacking plain HTTP connections does not necessarily have to inject code that harms the user's computer directly. He/she could also just alter bits and pieces of the served content to trick the user into doing something not in his/her interest.

So while having better browser sandboxing and protection is good (and welcome), HTTPS is still necessary.

And `pyenv` [1], for Python.

I came into `nodenv` after being a regular user of `pyenv` for a while. Started with `nvm`, but wished for something more pyenv-like.

There is also `asdf` [2], which seems even more generic. On paper it looks interesting, but I haven't found a solid reason to switch out of `pyenv` and `nodenv`.

Has anyone tried `pyenv` and/or `nodenv` and switched to `asdf`?

[1] https://github.com/pyenv/pyenv [2] https://github.com/asdf-vm/asdf

Type hints are machine-checkable documentation, similar to doctests in my view.

Since I started using them, the number of runtime errors coming out from my own code has been drastically reduced.

Of course one can always go overboard with those `Generic[T]` hints. Though this is a problem of the tool user, not the tool.

Why do you think it is the worst? If you don't consider Python, what would you then think is the worst?

Genuinely curious. I use Python daily and I rarely encounter problems with it. There is some getting used to in the beginning, but I went through a similar phase when I started using npm and cargo as well.

What I can say is that I had to go through a lot of experimentation myself to arrive at the tools I use now (pyenv + Poetry). And if anything, maybe the lack of one way that is adopted by everyone in the community is the problem.

how does the „two copies“ phenomenon of the human genome and the „two copies“ thing of chromosomes fit together? Are those one and the same concept?

Which phenomena are you referring to exactly? That we have two copies of each chromosome and if they mean we have two copies of the human genome?

Are there two copies of the XY chromosome, too?

Each of our non-sex cells[1] contain two sex chromosomes: one from our father and one from our mother. Since your mother always inherits her X chromosome, your sex is determined by which sex chromosome you got from your father. If you are a female (XX), your father passed on his X chromosome. If you are a male (XY), your father passed on his Y chromosome.

This rule makes for some interesting inferences. For example, your father in turn got his X chromosome from your grandmother and his Y chromosome from your grandfather (both on your father side, of course). Your mother, on the other hand, got his X chromsome from both your grandparents on her side.

So if you're a male, your Y chromosome was passed on from your grandfather on your father's side. If you're a female, one of your X chromosome comes from your grandmother on father's side, but your other X chromosome may come from either of your grandparents on your mother's side.

You can trace this Y-chromosome lineage back to what's called the Y-Chromosomal Adam, which is the last universal common ancestor of all currently living human males[2]. You can make a similar inference using your mitochondrial genome[3] and arrive at what we call the Mitochondrial Eve[4].

Our sex cells[5] are different, since they only have one copy of our chromosome set. The number of the chromosome set we have is called ploidy[6] and so our sex cells are haploid cells, as opposed to our non-sex cells, which are called diploid.

If you're a male, a single mature sperm cell in your body contains either the X or Y chromosome. For females it's different, since they only have the X chromosome, all their mature cells contain only one copy of the X chromosome.

[1] https://en.wikipedia.org/wiki/Somatic_cell

[2] https://en.wikipedia.org/wiki/Y-chromosomal_Adam

[3] https://en.wikipedia.org/wiki/Mitochondrial_DNA

[4] https://en.wikipedia.org/wiki/Mitochondrial_Eve

[5] https://en.wikipedia.org/wiki/Gamete

[6] https://en.wikipedia.org/wiki/Ploidy

I used to do print debugging a lot. And then I tried using the `breakpoint()` call available since Python 3.7[1], and now I can't imagine doing any serious debugging without PDB (or any other debugger).

(I mentioned Python, since this is linking to the Python-flavor of Icecream).

Sure, there are still times when just calling print() is sufficient. But they are becoming less frequent. `print()` is only shorter than `breakpoint()` by just 5 - len(variable_name_to_print) characters after all.

I know `import pdb; pdb.set_trace()` was available before, though `breakpoint()` is just a lot simpler, among others for the reasons they mentioned in the PEP.

There is also the `--pdb` flag in pytest[2], that lets me jump into a PDB session upon test failure.

All of this makes me think, what are the cases where print-level debugging is the better option in Python, compared to using an actual debugger?

[1] https://www.python.org/dev/peps/pep-0553/

[2] https://docs.pytest.org/en/latest/usage.html#using-the-built...

There is indeed no limitation on the number of tokens in a game.

There are many combo wins that involve having (technically) infinite tokens, dealing infinite damage, gaining infinite life, taking infinite turns. You get the idea.

I said technically because in practice, setting this to a very large number is enough for the win. Dealing 1e6 damage is, although possible, already way overkill in most cases when your opponent starts with 20 life.

Looks neat! Pattern matching is one of those features that I sorely miss when I have to program in Python.

I do feel a bit wary seeing this[1] though, given that `_` can be considered a special character in Python. I suppose you can use `ANY` instead of `_` in the pattern matches, but of course that would not look as clean.

[1] https://github.com/santinic/pampy/blob/4c8e6e0cabada82a5ed79...

It depends.

Another commenter mentioned Cram, which I would look into if checking stdout/stderr (mostly) is enough for my use case.

If I am already using a specific framework to write the pipelines, I would also look into whether it already provides ways for testing.

I am not aware of other tools that test for pre-/post- conditions, so I would probably start with mine and see if need to tweak things along the way.

One thing I am not too happy about the plugin is that sometimes setting up the process as a fixture can be quite verbose. It feels like this part can be improved with some more thought.

Some time ago I wrote a pytest plugin[1] that helps me test my long running shell scripts.

The idea was to treat the shell process as a fixture, and conditions before and after the test (input file checksums, output files, generated stdout/stderr, etc.) would be checked. It was mostly for data analysis pipelines (hence the name).

I don't use it as much these days as my days of writing long running pipelines are behind me. But for that time, it did its job pretty ok. It was also a nice way to peek into pytest's internals.

[1] https://github.com/bow/pytest-pipeline

Here's an example where it can be done in Angular: https://www.jvandemo.com/how-to-use-environment-variables-to....

Not exactly the same as shell environment variables, of course. And you may disagree about exposing the `enableDebug` flag as a runtime config there.

Still it is doable, in a sort of roundabout way, using the browser as the environment.

All of the leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment values at compile time. This practice requires that the static assets are generated for each environment and regenerated for any change to an environment.

As a backend developer that relies heavily on environment variables for configuration, I was surprised that runtime configuration is not something these frameworks recommend.

In the few occasions that I have to do some front end (Angular) stuff, I had to write my own service just so that I can have runtime configuration.

Why don't these frameworks support this out of the box? Are there any issues I may be missing?

FYI, the WHO [1] and CDC [2] post regularly on the status of various outbreaks all over the world.

For Ebola particularly, WHO posts weekly updates. And a cursory look of the most recent posts paints an increasingly worrying situation.

[1] http://www.who.int/csr/don/archive/year/2018/en/ [2] https://www.cdc.gov/outbreaks/index.html

Back when I was getting more serious about programming (2010-ish), I had to decide between Perl vs Python as those two were the most widely used in my domain (bioinformatics).

I remember one of the argument for Perl was exactly this: the vast number of libraries in CPAN. You would be able to do tasks much quicker because you would just need to install these libraries and go on with your tasks.

Still, I decided to go with Python because it made so many 'click' for me about programming in general + because of its REPL, among other things.

It turned out to be one of the best decisions I have ever made :).