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).🤷♂️
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.
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.
Is it just an extreme difficulty spike at this point that I have to trial-and-error through, or am I doing anything wrong?
I would say this is the biggest 'aha' moment for pretty much any developer - the first time you go from "I built this myself" to "A team built this and has supported it for 10+ years". Not only can a team of three or four write a lot of code in ten years - they'll optimize the Hell out of it. It's ten years worth of edge case bugs, attempts to go faster, new features, etc. And it's 'bumpy' because some of it was done by Dev A in their own style, some of it by Dev B, and so on. So you'll find the most beautiful implementation for problems that you haven't even considered before next to "Hello World" level implementation on something else.
The biggest thing you can do to help yourself out is make sure you're clear on their branching strategy. When you're the only one working on your code, it's cool to push to main and occasionally break things and no harm no foul. But for a mature code base, a butterfly flapping its wings on that obscure constructor can have a blast radius of 'okay, we have to rebase to the last stable commit'. When in doubt, 'feature/(what you're working on)'; but there might be more requirements than that, and it's okay to ask. Some teams have feature requests tracked by number, on a kanban board, some put it in their username, etc.
Get the code pulled down, get it running on your machine (no small task), git checkout -b from wherever you're pulling a branch off of (hopefully main or master, but again, it's okay to ask) and then, figure out what the team's requirements are for PRs. Do they have any testing environments, besides building it locally? Do they use linting or some other process to enforce style on PR reviews?
And then....don't move a button. (Unless that button actually needs moved!) But try to mimic something that already exists. Create a second button in the new location. Steal from the codebase - implement something small in a way that has been done before. After the new button works - then remove the old button and see what happens.
The longer you deal with a codebase (and the attendant issues and feedback) the more you'll feel yourself drawn to certain parts of the code that you're familiar with.
Anyway, hope that advice helps! But most of all, don't be scared. You will break things unintentionally. Your code will break things. If there's not a process in place to catch it before it happens, that's not your fault; that's the senior dev/owners fault. But do try to limit the damage by using good branching strategies, only PRing after linting/testing, and otherwise following the rules.
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.
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.