Eventually data has to be bound to code. Otherwise you'd have apps where you either have functional code running and other apps that are displays of raw data.
The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data.
Haskell style functional programming binds code to data at the last moment possible.
The best answer is likely somewhere in the middle, depending on your application and usage. I find, for example, that UI controls work well with OOP, but most other stuff I tend to default to functional style programming.
Declarative programming is also an option, where data is directly encapsulated into state, and programming entails describing the state transitions. SQL is a basic example of this, but it's also generally possible in other languages (eg template metaprogramming in C++). Prolog is a really cool language that operates solely on this principle.
Yes, it does seem like OOP and functional are on opposite sides of a spectrum. OOP is all about having and controlling state, while functional is about being stateless. I think my own code would benefit from being more functional, but that's hard to do in a OOP infrastructure.
I was fortunate in that I moved my team to Teams (I still find the name terrible) well before MS put a mandate out.
So our folks were comfortable once the MS EOL statement came out and the company started moving everyone over. Everyone else had quite a bit of a struggle for a week or so though.
On the plus side, I think there were very few complaints after a couple of weeks. Which probably had a lot more to do with how bad Skype for Business was (much worse than Lync) than how good Teams was (it was still fairly unpolished at the time...it's much better now...MS has been adding features and fixing issues rapidly).
If the reporter hasn't provided enough information to recreate the issue (it's obviously not a major deal breaking issue otherwise it would be obvious and easy to recreate) and they are internal to the company, tell them to provide more information before moving forward.
The author's approach is good for external bug reports, but they don't clarify that's indeed the case here.
I have to strongly appreciate the author for finding the root cause and tackling that instead of the symptom.
So often, especially in front end coding, you will see an exception being thrown because of a null value being passed in, and the "fix" checked in by the developer basically returns the default value if null is passed in, when they should be investigating and fixing why a null was passed into the function in the first place.
If your function has a contract that forbids nulls from You resolve the immediate bug, but this almost certainly leads to multiple bugs being created in the future (or worse, something that is quietly wrong, because 1 row in a 100 row table is missing and no one noticed) until the root issue is resolved.
Well, before this year there wasn't a global pandemic. That's really meaningless. This wouldnt be an issue if it had happened last year, or the year before, or the year before...1918.
The point is that any functional government would have accounted for the fact that there is a global pandemic, which if nothing else, might actually make it impossible for some students to even leave the US, before publishing this guidance.
Edit: Also, this is a deliberate undoing of a temporary allowance they had already made. From the first sentence of the linked document:
> Temporary procedural adaptations related to online courses permitted by the Student and Exchange Visitor Program (SEVP) during the height of the Coronavirus Disease (COVID-19)crisis will be modified for the fall 2020 semester.
Yeah, that's why the idea that H1Bs need to be restricted will help with US employment is remarkably stupid.
There are a few companies that abuse (abused?) the H1B program but that was always a small but visible percentage, but more importantly, actions taken under the Obama administration had drastically reduced the abuse.
The much greater percentage are employees who studied in the US, or worked with companies in India and then had them transfer to the US. Eliminating the H1B visa simply means that they will now do the same work from India or Canada instead, further reducing the number of jobs in the US.
People earning 80k in India, China, and heck even Europe, for that matter, almost certainly have a much higher standard of living than people earning that much in the US.
And you can find far more 80k level developers in individual cities in India than you would in a small mid level city in the US.
At some point where you live matters a lot. You can be rich, but if you can't get things shipped because the roads are bad, you can't get clean water, there are no local services around (haircut places, restaurants, tradespeople to fix your house), not to mention fun things to do, it looks worse.
I have this conversation with my friend Mike. I work and live in SF as a software engineer. He lives in Indiana and earns 8-10x what I do as a surgeon but I'm not sure he's actually better off. Especially considering there aren't great schools for him to send his kids to or interesting people to see in meetups.
This is pretty much completely anecdotal, and not very useful, to be honest.
The informal stuff doesn't work well. I'm guessing they went to buy their furniture off the informal buses during off peak hours. So they didn't have to deal with the crowds the majority of people have to deal with during regular rush hours, where you will find people hanging off the buses, and others struggling to get in. Sure, the bus may come every 5 minutes, but you may have to wait a few buses to get in.
Further, these are private buses. In the US you can get a cab exactly where you want that takes you exactly where you want. You could also "rideshare". The reason you dont have buses to do that in the US is because people can afford single occupancy cabs. What the person is really complaining about is the fact that the US is richer and things are more expensive.
A cab is a proper analogy to the private transport that is being compared to. And the real complaint is that earning dollars and then paying in dollars in the US is more expensive than earning dollars and then paying in local currency in the 3rd world.
> The reason you dont have buses to do that in the US is because people can afford single occupancy cabs.
It's much more complicated than that, though.
Public transport is looked down upon in the US—not just in the same classist way it is looked down upon in many places, "that's for the plebes", but like many public institutions, it is viewed by many to be inherently worse than private solutions, both ideologically and practically.
To a large extent, it is a victim of the deliberate practice of the American right wing, over the course of at least the last several decades, of reducing funding for public services (because Big Government Bad), then decrying their ineffectiveness (well, duh, they're not doing great because you took away half their budget), and pushing for them to be privatized.
Most roads in the US are public, and funded with taxation. Granted, it requires a private car to benefit from them. Still, this suggests that anti-government sentiments can only partially explain this aspect of US transportation.
When Huey Long was governor of Louisiana, he wanted to build roads. His opposition did not want to pay for roads. But he managed to wrangle enough budget for 60 miles of road. Then he paved one mile of road in each parish. After having experienced the difference between the single paved mile and their existing mud ruts, the populace voted for a much more substantial road-building program.
The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data.
Haskell style functional programming binds code to data at the last moment possible.
The best answer is likely somewhere in the middle, depending on your application and usage. I find, for example, that UI controls work well with OOP, but most other stuff I tend to default to functional style programming.