Douglas Crockford, author of “JavaScript: The Good Parts” has said:

“JavaScript is the only language in the world that people think they write without learning it first.”

I think this is a true statement (well, that and bash).

Not that I would recommend it, but you can also try something like extension methods on Func.

public static RunAndLog(this Func<T> f) {
 LogStart(f);
var x = f();
LogEnd(f);
return x;
}

I think you may have enough diagnostic info with reflection to write something meaningful, and you can add overloads with generic parameters for the func params, and/or Action.

You may also create an IDisposable that logs a start and end statement around a function call:

using var _ = CallLogger(“func name”) {
f();
}

Personally, I wouldn’t do either of these. This level of logging produces an enormous amount of noise, making finding signal very difficult. I would focus more energy on writing unique and helpful messages where they are important, and using git grep to find the related source code when they show up in production logs (assuming you don’t log a stack trace). This level of call logging can be temporarily useful while debugging or reasoning through an app, but rarely belongs in production.

You are really looking for architecture diagrams. These are extremely rare in most projects, open source or otherwise.

The reason you don’t see a lot of documentation on algorithms used or architecture is that most of the time the code is not actually novel. It’s like asking a plumber to describe the physical properties of the pipe they used on a job. They’d say “schedule 40” or “copper” and a dimension. They would not describe the manufacturing process or chemical composition of the pipe. The materials are pretty standard and only require special descriptions for when and why they deviate from those standards.

If these systems could only reorganize and regurgitate 1000 creative works, we would not be having this conversation. It’s literally because of the scale that this is even relevant. The scope of consumption by these systems, and the relative ease of accessibility to these systems is what makes the infringement/ownership question relevant.

We literally went through this exercise with fair use as it pertains to CD/DVD piracy in the 90’s, and Napster in the early 2000’s. Individuals making copies was still robbing creative artists of royalties before those technologies existed, but the scale, ubiquity, and fidelity of those systems enabled large-scale infringement in a way that individuals copying/reproducing them previously could not.

I’m not saying these are identical examples, but the magnitude is a massive factor in why this issue needs to be regulated/litigated.

Just to be clear, that is not exclusive to “engineering,” as other professionals have similar legal requirements (doctors, lawyers, fiduciaries).

More generally, on a personal level, people are expected to act with integrity, and we have laws that provide them legal protections for whistleblowing.

The actual practice of engineering is about problem-solving within a set of constraints. Of course the solution should not harm the public, and there are plenty of circumstances where software is developed to that standard.

When a PE stamps a plan, they are asserting that they personally have reviewed the plan and process that created it and that it meets a standard for acceptable risk (not no risk!). That establishes the boundary of legal liability. In software, we generally do not have that process that fits in a legal framework, but that doesn’t mean that professional software engineers aren’t making those assessments for life-critical systems.

For other kinds of systems, understand that this is a new field and that it doesn’t have the bloody history that got “real engineering” to where it is today. A lot of the work product of most software engineers just don’t have stringent safety requirements, or we don’t understand the risks of certain product categories yet (and before you try to rebut that, remember that “building codes are written in blood” because people were applying technology before it was well-designed/understood).

Anyway, “engineering” is defined by a lot more than if you or your boss has a stamp (and in point of fact, there are plenty of engineers in the US that work as engineers without being a PE, or with any intention of ever having the stamp. Are they real engineers?)

Well, a couple things:

My points are related to provable advantages to doing it while writing code. They’re also not argumentative.

Your points are related to a personal preference of aesthetic while reading code. They are not provable advantages. They’re also quite “ranty,” which is rarely a persuasive way to convince someone of your position.

If you actually want to get people to change their habits around this, I think you’ll have better luck with my approach than ranting about why you don’t like how it looks.

I think Roc has some ideas like this.

On a sandboxing level, I suppose we’d be talking about Unikernels (which seem cool, but the tooling didn’t look simple enough to experiment with them)

They basically aren’t?

If you’re doing one-off hobbyist stuff, maybe.

But literally anything in a professional setting should be in text that can be committed and searched in a source code repository. If you can’t commit it to git, it didn’t happen.

Interesting concept, just FYI, there’s a popular code grepping tool called Silver Searcher, and it also uses ag - consider just using august to avoid ambiguity/collisions.

It really depends on context, but if I’m just talking about estimating something, it’s usually rounding a decimal to a whole number or if it’s already a whole number, rounding it to the closest value that is divisible by 5 or 10.

Other than that, it’s basically just about reducing significant figures to make doing rough estimates more easily.

I know almost nothing about machine learning, but I think you want to look into Text Transformers or Large Language Models. What you’re describing looks like you’re trying to build a model that would typically be used for classification, which is not how generative text systems work.