// TODO: Leave the code cleaner than you found

In recent git versions (>2.23), git restore and git restore --staged are the preferred ways to discard changes in the working tree (git checkout -- .) and staged changes (git reset --) respectively.

My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

——On the cruelty of really teaching computing science - E.W. Djikstra

Yeah, I mean platforms accessible without so many hoops to jump through.

It’s believed that Glassdoor’s business model is to charge companies for removing bad reviews. So how much value can the rating provide is questionable in the first place.

Personally, for big companies, there are always people writing their work experiences on an open platform. For small companies, it’s unlikely to find a relevant review, if any, on Glassdoor anyway. So I never bothered to use it.

If you are looking at learning CS in a more holistic manner, there’s Path to a free self-taught education in Computer Science!. It’s a list of courses, categorized by topics, which are exactly what a CS undergraduate would learn. It might feel daunting at first, but you can pick any interesting topic and dive in.

I especially recommend CS50P for beginners.

One problem with exceptions is composability.

You have to rely on good and up-to-date documentation or you have to dig into the source code to figure out what exceptions are possible. For a lot of third party dependencies (which constitute a huge part of modern software), both can be missing.

Error type is a mitigation, but you are free to e.g. panic in Rust if you think the error is unrecoverable.

A third option is to have effect types like Koka, so that all possible exceptions (or effects) can be checked at type level. A similar approach can be observed in practical (read: non-academic) languages like Zig. It remains to be seen whether this style can be adopted by the mainstream.

Bingo!

Sean k strikes it again.

Yes for OCaml. Haskell’s inequality is defined as /= (for ≠). <> is usually the Monoid mappend operator (i.e. generalized binary concatenation).

Let me simplify it: proceeds to print the same expression

Deprecation warnings should contain suggestions for alternatives.

In general, given a Turing machine which outputs the result of a procedure to its memory tape, you can equivalently construct a recognizer of valid input/output pairs. Say P is the procedure, then the recognizer R is let (i, o) = input in P(i) = o

The reverse is also possible. Give a recognizer R, you can construct a procedure P that given part of the input (can be empty), computes the rest of the input that makes R accept the whole. It can be defined as for o in all-strings, if R(i, o) then output o and halt, else continue.

It might feel contrived at first, but both views can be useful depending on the situation. You’ll get used to it soon with some exercises.

For all possible input, only recognize the one input that’s (under certain encoding scheme) equal to the sum of the given list. That’s for a given list.

Another more general approach is that, only recognize the input if (under certain encoding), it’s a pair of a list and a number, where the number is the sum of the list.

Nah, in real CSS, the window would overflow and bring down the whole house.

Look, there’s a thing called safety-catch and that’s why my son can play with semi-auto rifles.

If you execute a binary without specifying the path to it, it will be searched from the $PATH environment variable, which is a list of places to look for the binary. From left to right, the first found one is returned.

You can use which cat to see what it resolves to and whereis cat to get all possible results.

If you intentionally wants to use a different binary with the same name, you can either directly use its path, or prepend its path to $PATH.

Sadly not its meta factory.

IMHO the reality is more complicated than what’s described here.

1. Open source is sustainable (in the sense that people will continue to do it), even without the maintainers getting paid, for better or worse. This is evidenced by the history and the majority of open source projects now.

2. The bait-and-switch problem, which gets the maintainers paid, hurts the ecosystem in the long run, which relies heavily on the good faith.

Static websites can be beautiful and easy to use without being complex.

PG’s blog and HN can definitely use some CSS tweaks. I can’t remember how many times I clicked the wrong thing in HN.

On the other hand, it’s easy to get reader mode/custom CSS/alt frontend working for such websites, so maybe it’s alright after all.