ddulaney

There are definitely some benefits! Installation and updates become trivial. Also, collaboration is generally easier, because all you have to do is send a link.

These are the same reasons Google Docs took off, and they are real advantages.

Although, “let’s flush this out” is also a hunting idiom, as in flushing out game. So that may be part of the confusion.

Can I ask what hardware you’re using? I’ve heard similar things on the internet generally, but I’m on a several-years-old phone and it took under a second. Is the interstitial really that slow on some setups?

It’s fascinating to me what a different view of risk we had in the past.

The no damage being caused on the surface was a “new fact”. That would never fly today, for better or for worse.

The general cost over a several large codebases has been observed to be minimal. Yet, there are specific scenarios where the costs are real and observable. For those rare cases, an explicit opt-in to risky behavior makes sense.

Yeah, exactly. If you're a developer, it can take a little bit to figure out that "docs like code" is a really strange concept to lots of non-developers.

The idea of using the same tools to manage your docs as you manage your code only makes sense if you understand what tools you use to manage code! If you don't -- if your main experience with documentation tooling is Word, or maybe MadCap stuff -- that's a really huge leap to make.

This system absolutely sucks.

If you ever find yourself on the wrong end of it, read this article for advice but also explanations: https://www.kalzumeus.com/2017/09/09/identity-theft-credit-r...

Understanding how the system works, which buttons work and which don’t is half the battle.

Rust’s Optional does close this altogether, yes. All (non-unsafe) users of Optional are required to have some defined behavior in both cases. This is enforced by the language in the match statement, and most of the “member functions” on Optional use match under the hood.

This is an issue with the C++ standardization process as much as with the language itself. AIUI when std::optional (and std::variant, which has similar issues) were defined, there was a push to get new syntax into the language itself that would’ve been similar to Rust’s match statement.

However, that never made it through the standardization process, so we ended up with “library variants” that are not safe in all circumstances.

Here’s one of the papers from that time, though there are many others arguing different sides: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p00...

Unfortunately, operator[] on std::vector is inherently unsafe. You can potentially try to ban it (using at() instead), but that has its own problems.

There’s a great talk by Louis Brandy called “Curiously Recurring C++ Bugs at Facebook” [0] that covers this really well, along with std::map’s operator[] and some more tricky bugs. An interesting question to ask if you try to watch that talk is: How does Rust design around those bugs, and what trade offs does it make?

[0] https://m.youtube.com/watch?v=lkgszkPnV8g

The map is drawing Germany and Czechia both with the same white color as the border.

Unfortunate that the color scheme is confusing, but not any weird borders.

You can see the uncolored map here: https://en.m.wikipedia.org/wiki/File:BlankMap-World6-Equirec...

I think the issue is that CSV parsing is really easy to screw up. You mentioned delimiter choice and escaping, and I’d add header presence/absence to that list.

There are at least 3 knobs to turn every time you want to parse a CSV file. There’s reasonably good tooling around this (for example, Python’s CSV module has 8 parser parameters that let you select stuff), but the fact that you have to worry about these details is itself a problem.

You said “handling data is complicated as much as the world itself is”, and I 100% agree. But the really hard part is understanding what the data means, what it describes. Every second spent on figuring out which CSV parsing option I have to change could be better spent actually thinking about the data.

If you even can with ASLR. Most modern boxes would disable stuff like this.

They just wanted the CLA to support the (paid) relicensing.

I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.

The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.

I don’t think it would’ve in our case, at least. I actually quite like our OSS policy: basically, we don’t want to be in the business of maintaining forks, so all changes should try to get upstreamed if at all possible. It‘s good client service as well: when our clients ask about the libraries we use, we’d much rather be able to tell them “the latest public version” than “here’s our fork”.

We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.

We (engineers) actually wanted to for another GPL’d project! But because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.

We probably would’ve for LZO too; not sure why that fell through.

The last 2 paragraphs of this interview with David Chisnall really made me think differently about that: https://lobste.rs/s/ttr8op/lobsters_interview_with_david_chi...

In particular:

I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component.

It also aligns with my experience: my company couldn’t find an LZO compression library that wasn’t GPL’d, so the decision was between implementing one in-house or cutting the feature. We ended up restricting use of the feature to in-house use only, but opening up our core source code was never an option.

If there had been a permissive license option available, we would’ve likely donated (as we do to several other dependencies), and would’ve contributed any fixes back (because that’s easier to explain to customers than “here’s our patched version”).

There's also a sort-of informal "standard library" of C libraries that have super-stable ABI's that we can generally assume are either present on the system or easy to install. Zlib is another one that comes immediately to mind, but there are others as well.

I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible.

You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.

It doesn’t help that they made an absolute ton of them: something like 140,000! That means that they’re not particularly rare, and it holds the price down.

Add in the fact that authenticity is part of the appeal, plus the fairly expensive process to make a decent replica, it’s not shocking that no replicas have emerged, even though cheap-ish CNCs mean it’s probably easier to do than it ever has been.

The podcast is super fun! It takes the “Engineering Podcast with Slides” model that WTYP originated, but instead of having one knowledgeable person and two comedians, all 3 know different parts of the industry.

She wrote an update last year about the frequency changes: https://admiralcloudberg.medium.com/why-so-few-articles-late...

Definitely worth subscribing to email updates!

Often used by people who are American (from the Americas) but not from the US. Canada, Mexico, Brazil, Columbia, and the rest of North and South America.

Exchange trading happens in round lots that are usually 100 shares.

This is pretty much just a legacy thing, but so many technical systems have this assumption built in that while odd-lot trading (trades not in the round lot size) has become a little more common on the exchanges, it’s still treated weirdly by the various systems involved.

But also, it’s better for you as a retail investor, to get them from a middleman, because they will generally give you a better price than the exchange. They will give you a better price because retail traders tend on average to be worse at trading than the overall market. You should take advantage of that, regardless of your actual ability level.

Yeah but also all of the legacy baggage that it comes with, y’know?

Like the URL parsing stuff for example. The issue is that they pull in one of these enormous old RFC’s and also say “but UTF-8” without any more explanation.

A better URL might be a good thing — scope it down to what’s in common use, design it tightly for your needs, etc. But if you’re gonna do that, do it! Rather than just pulling in an RFC with decades of baggage and then modifying it ad-hoc.

The only reason to sell any of your company is to raise money. If you can raise all the money you need from your employees, then you can be employee-owned.

https://kaitai.io/ maybe?

It looks perfectly nice for its role, but I didn’t use it for my last project because I need serialization as well.

See also this review/critique from the cURL author, especially if you’re going to implement it yourself. Particularly around certificate handling and URL parsing, there’s a lot of underacknowleded complexity in Gemini.

https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-s...

Default configuration IMO.

I actually really like the way git does it, where it reads each of these in order, last one wins.

- Default configuration compiled in

- Global configuration

- Per-user configuration

- Per-project configuration

You can opt-in to however much configuration complexity you need. Just cloning the occasional thing? Don't bother configuring, the global defaults are probably good enough. Simple commits and pushes? Make a user-level dotfile in your $XDG_CONFIG_HOME to set some basic info. Complex per-project aliases? If you want that, go ahead and opt in.

Contrast that with programs that just dump their whole default config into my home dir on first run. Just filling up with nonsense, often no way to tell what I changed or didn’t.

That’s a super good point.

Part of the issue is that ID’s are expensive. When I moved from one state to another a couple years ago, a new driver’s license was $50. There’s a long history of poll taxes used for voting suppression in the US, so any kind of pay-to-vote concept is tough. (The easy answer, of course, is to make ID issuance free.)

Then there’s the issue that states have widely different levels of competence regarding ID issuance. The REAL ID Act [0] required states to start issuing IDs based on more robust requirements by 2008. That deadline has been delayed through 2025, and is likely to get pushed back again.

When I lived in Kentucky (stereotypically poor and rural), there was a major issue that birth certificates were handwritten and never digitized, and existing driver’s licenses had been issued based on what you claimed your name was. When they started validating birth certificates as a part of REAL ID, people ran into issues when the name they had been using for their whole life didn’t match what was handwritten on their birth certificate.

Basically, identity documents are local (and often hyper-local; my own birth certificate is certified by my county, not even my state). Dragging the whole country into something resembling modernity is a major project that will exclude big chunks of people that are otherwise “responsible”.

Making the right to vote dependent on that whole system happening to work out OK for you just doesn’t seem like a good idea.

[0] https://en.m.wikipedia.org/wiki/Real_ID_Act

When government IDs are universal, we can require them to vote.

Here's a study from about a year ago: [0].

Upshot is that 21% of Americans 18 and older don't have an ID that matches their name and address. Disenfranchising a fifth of Americans isn't something I'd accept.

Note also that it's 23% of Democrats, 16% of Republicans, and 31% of independents. You can see why Democrats are anti-ID-check while Republicans are pro-ID-check as a general rule.

[0] https://cdce.umd.edu/sites/cdce.umd.edu/files/pubs/Voter%20I...