Confused what you mean. OpenAPI has nothing to do with JS.

Omaha is a lot less left-leaning in my experience. It’s very purple. Lincoln is solidly blue.

I just recently purchased a house in Lincoln. Just quickly looking on Zillow for Omaha and home prices look to be very similar to what I was seeing here in Lincoln. Property taxes in Omaha are also a fair bit higher than Lincoln.

There’s other stuff too, like lower crime rate in Lincoln, better/more parks, LPS being generally a lot better than OPS, etc.

I guess it ultimately depends on what you’re after. If you want something more big city, then Omaha obviously has Lincoln beat. But for a more relaxed pace of life and for raising a family, Lincoln is where it’s at.

There are a number of blue cities in the Midwest. What’s the lowest temp you want? I live in Lincoln, Nebraska and it’s pretty great: nice weather most of the year, low cost of living, blue city, tons of parks. Only downside is dealing with red state bullshit from the state government.

Oh you mean stuff nobody actually asked for?

Pretty dumb, honestly. If anything it just adds a Streisand effect to it as people try to figure out what’s censored.

Not that censoring it has any value whatsoever. Like if a child sees that, so fucking what?

Yeah it’s not all that uncommon in school, just increasingly uncommon in industry.

Visual… programming languages? Yikes.

Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.

Except I never said sticky keys shouldn’t exist. And no, I’m also wasn’t saying that literally every disabled person ought to go out and buy a programmable keyboard. So many assumptions in this thread.

Wow, what a disproportionate and oddly vicious response to a very innocuous suggestion.

Nowhere in my comment did I suggest that sticky keys simply shouldn’t exist. I was specifically responding to the OP talking about Ctrl-C/V and suggesting that a programmable keyboard would be a better solution for that, since you can turn 7 keystrokes into 1, since I expect that reducing the number of keystrokes one has to type is probably pretty valuable for someone in this situation. There are a lot of standard keybinds in an OS that could be handled this way. Obviously you can’t do this for every keybinds in existence. But again, the OP was talking about standard OS keybinds. Admittedly, I forgot sticky keys are a toggle, so it’s not as many keystrokes after the first time, but still, there are common key sequences that would be more challenging to hit, like Ctrl-Alt-Delete.

If someone is trying to use a public computer, by all means, use sticky keys. Again, I never said it shouldn’t exist or people should never use it. I was pretty obviously talking about the normal case: using a workstation/laptop at work/home. It’s kind of implied when referring to an external keyboard, since you don’t usually bring those places. Don’t really know why you’re talking about public computers.

The rest of your weirdly personal attacks are all against a strawman you’ve constructed, so I don’t really need to address them.

If the MR is anything bigger than a completely trivial change in a file or 2, it most likely should be broken into multiple commits.

A feature is not atomic. It has many parts that comprise the whole.

deleted by creator

Commits should be reasonably small, logical, and atomic. MRs represent a larger body of work than a commit in many cases. My average number of (intentionally crafted) commits is like 3-5 in an MR. I do not want these commits squashed. If they should be squashed, I would have done so before making the MR.

People should actually just give a damn and craft a quality history for their MRs. It makes reviewing way easier, makes stuff like git blame and git bisect way more useful, makes it possible to actually make targeted revert commits if necessary, makes cherry picking a lot more useful, and so much more.

Merge squashing everything is just a shitty band-aid on poor commit hygiene. You just get a history of huge, inscrutable commits and actively make it harder for people to understand the history of the repo.

Just remember that if you aren’t actually concatenating files, cat is always unnecessary.

If you mean for programming specifically, I… don’t, really. At most it would be for a quick sanity check on syntax in a language I don’t write often, for which Google is fine. But otherwise I rely on documentation and search features of the various language/tool-specific websites.

https://porkmail.org/era/unix/award#cat

jq < file.json

cat is for concatenating multiple files, not redirecting single files.

Meanwhile, I can open a 1GB file in (stock) vim without any trouble at all.

Formatting is what xmllint is for.

:syntax off and it works just fine.

I understand what you’re saying—I’m saying that data validation is precisely the purpose of parsers (or deserialization) in statically-typed languages. Type-checking is data validation, and parsing is the process of turning untyped, unvalidated data into typed, validated data. And, what’s more, is that you can often get this functionality for free without having to write any code other than your type (if the validation is simple enough, anyway). Pydantic exists to solve a problem of Python’s own making and to reproduce what’s standard in statically-typed languages.

In the case of config files, it’s even possible to do this at compile time, depending on the language. Or in other words, you can statically guarantee that a config file exists at a particular location and deserialize it/validate it into a native data structure all without ever running your actual program. At my day job, all of our app’s configuration lives in Dhall files which get imported and validated into our codebase as a compile-time step, meaning that misconfiguration is a compiler error.

You’re just describing parsing in statically-typed languages, to be honest. Adding all of this stuff to Python is just (poorly) reinventing the wheel.

Python’s a great language for writing small scripts (one of my favorite for the task, in fact), but it’s not really suitable for serious, large scale production usage.