bignavy
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.
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.
When you do your job as a developer so good you have to allow users to use a whole programming language to get the functionality they need.
Although this might speak to the abuses of excel in the business world more than the failures of excel, tbh. Maybe both?
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).🤷♂️
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.
I think sometimes the difference between strongly typed and loosely typed is easier to explain in terms of workflow. It’s possible (note: not necessarily a good idea, but possible) to start writing a function in vanilla JavaScript without any real idea of what it’s going to output. Is it going to return a string? Is it going to return null, because it’s performing some action to a variable? Or is it going to return that variable? And vanilla JS is good with that.
But that same looseness that can be kind of useful when you’re brainstorming or problem solving can result in unexpected behavior. For instance, I write a function that prepares a string for additional processing. For the purposes of this conversation, let’s say that it removes white spaces and any non-letter or number characters, and then returns the transformed string.
What happens if I feed a number (integer) to this function instead of a string? What about a number with a decimal (float)? Does my function (and/or JavaScript) treat them as literal strings? Does it remove the decimal from the float, since it’s a non-letter, non-number value?
Without Typescript, you have to either a) write your code in such a way that you ensure that the situation never comes up (i.e. by validating inputs, or by being very careful about when and how this function is used), or b) you have to handle those weird cases, which turns a cute little three line function into a 30 line monster with a switch case and typecasting. And truthfully, on any project ‘at scale’ you’re going to have to do both.
With Typescript, you specify that this function takes in a string, and returns a string, and that’s it. Then, when another dev (or you, in six weeks when you’ve forgotten all about this function that you wrote) tries to send in a boolean, or a float, or an array of strings, Typescript is going to blow up. Nope. Can’t do that. And they (it’s more fun to think of it as future you) will have to follow the rules that you put in place by writing the function the way you did, which just means being careful enough to cast a float or integer into a string before passing it, or concatenating an array, or whatever.
Strongly typed languages expect you to write functions with the end state you’re expecting in mind. You’ve already got the solution in your head before you start typing, at least enough to know what type of data goes in and what type of data goes out.
It also hides (but doesn’t totally get rid of!) some of the sillier things that JavaScript does because it’s not strongly typed. True + True should probably never equal 2.
As to OP’s question, though - if you know how to do things in JavaScript (.trim(), for example), then you know how to do a thing in Typescript. Manipulating data in JavasScript and manipulating data in TypeScript is identical - but TypeScript is also watching what the types of the different data types being used, and throwing up the BS flag when you get too loose with what you’re doing (or don’t think through the consequences of your design decisions).
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.