Even though my experience is basically the same as the author's (8y using java/kotlin toolchain), the article still seems to be written by someone with a hammer frustrated with screws for not working properly. His points can be summed up as "Flutter isn't as stable as the java toolchain that has existed for over a decade" and "I want Flutter to work the way I am used to work".
> Intel CPUs across the world can almost painlessly be swapped for AMD CPUs right now and only a small fraction of users would have to change anything.
I beg to disagree here, swapping CPUs would definitelly prove to be extremelly costly in every possible way. Not only do the MoBo + CPUs themselves have a cost,
but they also do not exist. That would mean a huge spike in AMD (or whatever vendor) demand, one that they don't even have the capacity to manufacture.
On top of that, all the kernel optimizations over the years, which have a big impact in the overall costs of a cloud service, would be lost.
All that ignoring the logistical side of swapping motherboards and CPUs, transport, risk and everything.
> SQL is a very high level of abstraction, to the point where the argument is a bit absurd when compared to a very concrete example of COBOL. Yes, if we had to rewrite everything that utilized SQL then it would take an incalculable amount of effort.
You're right. Let me swap that with OracleSQL or MySQL, that'd make more sense.
> I feel like you're kind of hitting the nail on the head with the Linux kernel bit though -- yes we could replace all uses of the Linux kernel with one of the many alternatives available, but it would take a long time. More likely we'd see a major transition to one of the other available kernels. This is exactly the situation COBOL is in.
Imo the Linux kernel position is not the same as COBOL. COBOL is mainly being maintained, whereas Linux is the current standard for new projects and will remain so for the foreseeable future.
If we create a new project running on COBOL, or a new project running on a Linux server, those are two completely different situations.
> All this though -- and I think we're just talking about a semantic difference on the use of "%1 powers the %2". Arguably C, SQL, and Javascript provide the value to users which encourages them to spend their money which encourages further development. So okay, I think I follow where you're coming from. COBOL doesn't power the economy, it's just the most common form of infrastructure for us to extract value from the economy. That sound a bit more correct?
Yes, exactly my point. The economy is not "powered" by banks, it is powered by those who create economic value, and they do not use COBOL all that much.
My point is, COBOL is responsible for a really small % of said value per value transaction between me and said services. Linux, [Oracle/My]SQL, Java, JavaScript, C, anything from router firmware to Intel cpus powering the VMs is more relevant than said COBOL code.
So saying COBOL powers the global economy is indeed a stretch. Want to say Linux powers it? True, Intel powers it? True. COBOL... not so much. Imagine rewriting every COBOL system in the world, now change that into replacing all Intel cpus, ~~SQL~~ OracleSQL or MySQL databases or Linux kernels...
Edit: saying "SQL Databases" makes as much sense as saying "procedural programming languages", updating it to make more sense
I hate how the title says "powers the global economy" when it should be "powers banking systems". I spend a lot of money on many things, my smartphone, gsuite, slack, Netflix, Amazon, Dropbox, games, tools, hardware, and I would guess most of that stuff never touched Cobol. Meanwhile I pay 1usd monthly for my bank (which, btw already migrated). So saying it "powers the global economy" is definitely a bit of a stretch.
I am sure there's a lot of it running still, mission critical stuff, also that there are still a few teams creating new projects with it. So it is not dead by this definition. But if I'm honest, I can't name one single language that is.
What goes around, comes around. Stealing code is on Microsoft records, as a simple "Microsoft admits stealing code" search shows. One can only wonder how much code the company stole that did not come to public knowledge.
Automatic emergency breaking and other "safer human-driven" cars is not making the human-driven aspect any safer, but rather putting the working and stable parts of autonomous vehicles as a tool for unsafe human-driven vehicles. That said, it will obviously fare better than fully autonomous vehicles, but it is still just a part of autonomous vehicles in general. In this sense, these cars are not "a problem self-driving cars have" as the title implies, they are actually a stepping stone for self-driving cars.
We just have to make sure we are not swapping super processed meats with super processed plant-based foods. Avoiding processed foods is what makes up for most of this difference.