They’re not demanding anything. They’re describing how the current meaning of REST is nothing like the original one.

They’re making a point for not splitting application state and logic into client and server with shared knowledge. If you’re making that a pretext of course their argumentation won’t fit. They’re describing an alternative architecture and approach. Not an alternative protocol for the current common web application architectures.

Presentation/Lecture; bad software quality due to software stack complexity with increased separation of layers and participants

SoC (System on a Chip) hardware for embedded/smaller use cases is very common and successful.

Suggests “Direct Coding” with direct hardware access as a possible alternative approach to PC hardware interfacing. Implementing that is more about commitment than difficulty. Depends more on hardware producers than software developers. A lack of drivers could give a fairer playing field between manufacturers.

German pro basketball team relegated to lower division due to Windows update

lol

Seems like a Ruby issue and suggested improvement? Using keyword arguments does feel like introducing a type of typing.

In C# I use records for simple, naturally behaving types, I can define explicit and implicit cast operators, so I have to choice between requiring explicit casts or not (because they make sense to require or are not necessary). I can use var to define a variable without specifying a type, and it is deducted from what it gets assigned - but is still that specific type and gives me type safety.

In Rust, as far as I understand anyway, traits define shared behavior. In Go interface implementations are implicit rather than explicit. With these, there’s even less of a need of elaborate explicit typing like the post argues/gives an example of.

In general, I’ve never had considerable effort or annoyance implementing or using typing. And I know what it’s good for; explicitness, and in consequence, predictability, certainty, increased maintainability, and reduced issues and confusions. If following references or refactoring becomes unpredictable or high effort, it’d be quite annoying.

When I’m coding JavaScript adding JSDoc so the typing information gets passed along is quite cumbersome. Without it, the IDE does not give intellisense/auto-completion or argument type matching. JavaScript is better with it, I consider it worth it with IDE support, but it is quite cumbersome. (I try to evade TypeScript compiler/tooling overhead.)

A programming language can offer extensive auto-deduction while using strong typing. With appropriate conversions in place, it will only report conflicts and where it was intended to.

I’m thinking of where I enjoyed dynamic natures, which I certainly have. But I don’t think that’s a matter of typing. It’s a matter of programming language interfacing to typing. If in PHP or JS I make a change, hit F5, and get an error, that’s not any better than the IDE already showing it beforehand. And for the most part, I can program the same way with or without typing.

Man, this became a long text.

I’m just glad we didn’t end up with this one (seen in the ticket)

Damn, sad story behind the color

deleted by creator

The field is incredibly broad. Choose a field or employer or project that’s not doing that an you’re fine.

Are you sure? I’m not very active in that ecosystem, but if that was prevalent in the past, surely there’s still tutorials and stuff out there that people would follow and create such projects even today?

More than that, it seems to me that the official python docs for packaging [still] talks about setup.py. Why would people not use that?

got it; arse

It would certainly be an issue if you didn’t have one

The problem was named after an incident in 1996 in which AOL’s profanity filter prevented residents of the town of Scunthorpe, North Lincolnshire, England, from creating accounts with AOL, because the town’s name contains the substring “cunt”.

haha

those are terms, this is substrings within words

I haven’t seen branches or variables being called arse

Then again, I do like to catch exceptions as up so I can throw up

Simple changes require only simple reviews.

Responsibility is shared. It’s not one or the other.

Many people don’t know what they’re doing. That’s kind of expected. But a tool provider and seller should know what they’re doing. Enabling people to behave in a negative way should be questioned. Maybe it’s a consequence of enablement, or maybe it’s bad design or marketing. Where criticism is certainly warranted.

Commit with Co-authored-by: Copilot

or maybe better --author=Copilot

It would certainly help evaluate submissions to have that context

he l p

looks like a multi-threading or concurrency issue

each function has its own independent metal toggle switch

one steering wheel to steer left, and one to steer to the right

they want to push a lot of buttons on those controls

LOL

Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.

Have you considered creating a ticket called “Can’t ask questions without joining discord”?

Do you think it would have more answers if it were on GitHub discussions?

Release must be documented

It’s not a must [unless you put it into a contract], it’s a should or would be nice

Many, if not most, projects don’t follow a good, obvious, transparent, documented release or change management.

I wish for it, too, but it’s not the reality of projects. Most people don’t seem to care about it as much as I do.

I agree blind acceptance/merging is problematic. But for some projects (small scope/size/personal-FOSS, trustworthy upstream) I see it as pragmatic rather than problematic.