This is the real answer.
There are still, in the year 2023, Cobal developers graduating and getting hired to work on software.
My alma mater’s website runs on PHP.
The investment to flip even a microservice from one language to another is REALLY high, and most companies won’t pay unless there’s a significant pain point. They might not greenfield new projects with it anymore - but it will still be around effectively forever.
You’re not wrong. Having to figure out which element is borked in a yaml file is not great. And the implementation using yaml is all over the place, so even though tools do exist, they’re mediocre at best.
But, to be fair, Python has always done the same to me. As a fellow Neuro-spicy (and with a background in Java and C# and JavaScript), although the tools are better to point you in the right direction, significant white space (or indentations) are significant white space (or indentations).🤷♂️
Not sure whether fantastic troll or just no exposure to Python.
Either way....I'm here for it.
The last couple of years his catch-and-shoot and off-the-dribble numbers are basically identical. Actually since about 2017 he's been a better catch-and-shoot than off-the-dribble shooter - but again, it's close.
I agree with you that he's quit on three teams in a row and still wants a big role in an offense wherever he goes - but I think my point is valid, too. If he could resign himself to being the third best guy on a team, he's still got enough in the tank to be value added.
He's not washed - he's just an asshole. 😂
Real talk, though - you're getting at least a 50% chance he shows up out of shape, a 100% chance that he'll quit on you at some point, and even if those two things don't pop, he's never exactly been a lock down defender. But he can still create shots and hit 3s at a decent clip. He's basically the better version of Seth Curry, if Seth insisted on having the entire offense run through him.
Man it’s a good thing that Darryl Morey didn’t like, take a huge gamble on him, based on their history together.
Oh.
James Harden was a transcendent offensive talent, even though he’s never been much fun to watch. But I can’t remember a player who has had a sadder (or quicker?) descent from MVP-caliber to actively cancerous ring-chaser.
He’ll still probably get a ring, somewhere. IF (and it’s a big if, actually) he can stay healthy, stay in shape, and be comfortable actually being the third or fourth best guy on a title team.
The most compelling argument I heard is that WASM can’t manipulate the DOM and a lot of people don’t want to deal with gluing JS code to it, but aside from that
But other than that, Mrs. Lincoln, how was the play?
You've gotten several other answers that are true and correct - the pain of implementation at this point is greater than the pain points that WASM solves. But this is also a non trivial one - most of what Javascript should be doing on a webpage is DOM manipulation.
At some point, WASM will either come out with a killer feature/killer app/use case that Javascript (and all the libraries/frameworks out there) hasn't figured out how to handle, and it will establish a niche (besides "Javascript is sort of a dumb language let's get rid of it"), and depending on the use case, you might see some of the 17.4 million (estimated) Javascript developers chuck it for....what? Rust? Kotlin? C? C#? But the switching costs are non-trivial - and frankly, especially if you still have to write Javascript in order to manipulate the DOM....well, what are we solving for?
If you're writing a web app where one of the WASM languages gives you a real competitive advantage, I'd say that's your use case right there. But since most web applications are basically strings of api calls looped together to dump data from the backend into a browser, it's hard to picture wider adoption. I've been wrong before, though.
For a second I thought my github was going viral. ;)
This is a hilarious (and interesting!) read.
As a young(er) and slightly shittier web developer, before I really understood or could implement promises effectively (or when my code would 'race' and fail to recognize that the DOM hadn't been loaded yet, so I couldn't attach event listeners yet), I was known to implement a 2 second timeout.
It wasn't pretty, but it worked!
I’m a web dev turned DevOps (with the front end design eye and CSS knowledge of a DevOps! Lol) but this seems like a great place to use a css grid, no?
Junior-ish DevOps with some blue/green experience.
It’s a very thorny problem, and I think your willingness to put up with the trade offs really would drive what patttern of architectecture.
Most of our blue/green deployment types use a unitary database behind the backend infra. There’s a lot ways to implement changes to the database (mostly done through scripting in the pipeline, we don’t typically use hibernate or other functionality that wants to control the schema more directly), and it avoids the pain of trying to manage consistency with multiple db instances. It helps that most of our databases are document types, so a lot of db changes can be implemented via flag. But I’ve seen some SQL implementations for table changes that lend themselves to blue/green - you just have to be very mindful to not Bork the current live app with what you’re doing in the background. It requires some planning - not just “shove the script into source control and fire the pipeline.”
If we were using SQL with a tightly integrated schema and/or we couldn’t feature flag, I think we’d have to monkey around with blue/greening the database as well. But consistency is non trivial, especially depending on what kind of app it is. And at least one time when a colleague set up a database stream between AWS accounts, he managed a circular dependency, which….well it wasn’t prod so it wasn’t a big deal, but it easily could’ve been. The data transfer fees are really what kills you. We managed to triple our Dev AWS bill prototyping some database streams at one point. Some of it undoubtedly was inefficient code, but point stands. With most blue/green infra, your actual costs are a lot less than 2x what a ‘unitary’ infra would cost, because most infra is pay for use and isn’t necessary except when you go to deploy new code anyway. But database consistency, at least when we tried it, was way MORE expensive than just 2x the cost of a unitary db, because of the compute and transfer fees.
Like the SEAL who became a doctor and then went to space. Don’t feel like you have to limit yourself, you know?
You got downvoted for being sympathetic - and it also happens to be the right reason.
I prefer to use a Bluetooth earbud. But a lot of times even with the phone turned up and smooshed against my face - I just can’t hear. Especially in loud places.
I can, almost always hear my speaker - and I can have my hands free and interact with my phone too.
I don’t do this in public, mind. But I could see it being a hard habit to break.