C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.

I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you're commenting on.

This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can't compile it with a C++ compiler because it introduces a series of backwards incompatible changes.

It's also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?

C++ programmers mocked languages for being dynamically typed then they introduced auto (...)

I'm sorry, you are clearly confused. The auto keyword is not "dynamically typed". It is called "auto" because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?

Your comment sounds like trolling, frankly.

It doesn’t matter, why the present is garbage, it’s garbage and we should address that. Statements like this are the engineering equivalent of “it is what it is shrug emoji”.

I don't think your opinion is grounded on reality. The "it is what it is" actually reflects the facts that there is no way to fix the issue in backwards-compatible ways, and it's unrealistic to believe that vulnerable frameworks/websites/webservices can be updated in a moment's notice, or even at all. This fact is mentioned in the article. Those which can be updated already moved onto a proper authentication scheme. Those who didn't have to continue to work after users upgrade their browser.

Boy, does that group sound like the ultimate bunch of social climbers trying to make a living out of someone else's work.

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

Yes, OP's attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

OP,

Here's a friendly reminder that programming.dev has a community dedicated to .NET: !dotnet@programming.dev

If you need anything more complex than cherrypick, you already screwed up big time.

I think this is a clueless comment. You can use Git to greatly improve your development workflow if you dare going beyond the naive pull/commit/push workflow.

Take for example interactive rebase. It let's you do very powerful stuff such as changing the order of commits in a local branch and merge/squash contiguous commits. This unlocks workflows such as peeling off bugfix and cleanup commits from your local feature branch without having to switch branches. I'm talking about doing something like:

a) - you're working on your task, b) - you notice a bug that needs fixing, c) - you fix the bug and commit your fix, e) - you continue to work on your task, f) - you notice a typo in your bugfix code, so you post a fixup commit. g) - you post a few commits to finish your task, h) - you noticed your bugfix commit didn't had the right formatting, so you post a couple of commits to lint your code both in your bugfix commits and task.

When you feel you're done, you use interactive rebase to put everything together.

a) you reorder your commits to move your bugfix commit to the top of your local branch, followed by the typo fixup commit and the linter commit. b) you mark both the typo and linter commits as fixup commits to merge them with the bugfix one, c) you post a PR with the single bugfix commit, d) you finally post a PR for your task.

Notice that thanks go git interactive rebase you did not had to break out of your workflow or do any sort of context switch to push multiple PRs. You just worked on things you had to work, and in the end you just reorganize the commit history in your local branch to push your work.

Is this what you call "screwed up big time"?

You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.

The only time I had to brush up on data structures and algorithms is when I apply to job ads, and recruiters put up bullshit ladder-pulling trivia questions to pass to the next stage of a recruiting process. It's astonishing how the usefulness of a whole body of knowledge is to feed gatekeepers with trivia questions.

must have been a half ass attempt

How hard do you need to try to use a feature for it to be considered decent? Do you expect something as basic as a search to put up a fight?

We spend so much time building devices that are meant to break, and be unfixable, and making software that fights the user instead of helping.

Kudos to the EU for forcing mobile phone manufacturers to support replaceable batteries and standardize on USB-C charging.

What really helped me get better as a software engineer was going out of my way to progressively learn as many software design patterns as I could and iterate over pet projects to refactor them to apply them in practice. It helped me write cleaner code that's far easier to maintain and extend, it helped me be far more efficient at onboarding onto projects, it helped me greatly improve my skills as a software architect.

Is it just me or is this a nightmare implementation in terms of software maintenance and operations? Each state transition requires a database trip, state machine transitions are determined at runtime and there's no simple way to reproduce them locally, and in the case of the state machine database going down the system simply cannot work.

What exactly is the selling point of this approach?

Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.

Story time.

Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.

I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn't complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.

So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.

All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.