sigh

I’m so tired of repeating this ad nauseum. No, it’s not going to take your job. It’s hype train bullshit full of grifters. There is no intelligence or understanding, nor have we come anywhere close to achieving that. That is still entirely within the realm of science fiction.

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.

As someone that has recently taken an infant and and family CPR class for my son who started solid foods a few months ago, this is pretty similar to how they teach it today and I’m pretty sure it would have the same effect. You can’t perform a heimlich on a baby or very small child for a variety of reasons. This method or something similar to it is both safer and more effective, since it lets gravity help dislodge the food.

Visual… programming languages? Yikes.

Never do certifications for software engineering. The only certifications worth a damn are security certs and networking certs. If I saw a programming-related certification on a resume, I would completely ignore it since the only thing it tells me is that you paid some money to get a cert.

While I’m not a fan of Java, it’s most certainly not a dying language and you will be able to easily find employment into perpetuity. If I had to pick, I’d personally choose Java over .NET purely to avoid being trapped in Microsoft-land, especially with all of the bullshit they’ve been up to lately.

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.

https://curl.se/ has been account free since 1998.

Never understood why people keep trying to use proprietary tools for this, especially when curl is so good.

I have a directory of shell scripts I use to test out endpoints. I persist request/response data either with environment variables or regular files. Oh and since these are just shell scripts, it’s pretty trivial to do stuff like iterate over a CSV (or JSON array) and make a request for each row, conditionally make requests, or whatever else you want.

Oh and honorable mention goes to jo and jq for making it super easy to make/process JSON data.

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.

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.

Given that this vulnerability was due to a use-after-free, definitely the language. Such a thing is impossible in memory-safe languages (Rust being the most obvious comparison).

Yeah, interoperability. Like every software implementation of natural numbers that include 0.