No. Who said single this out? Instead we should just do better.
Concepts should be carefully named because this is not just jargon between a tiny handful of highly competent and super technical people; a vast number of devs and non-technical users will use these terms and it is in everyone's best interest to use descriptive and sensible wording.
Data lakes, data factories, event hubs are product names, not concepts, but they are either exactly the same as their underlying concept, or very closely related. However, as stated for the 3rd time, serverless is not. It's completely inaccurate and vague.
Where did you get that "serverless" means function as an entry point with 2 params? Every platform is different, from entry points to parameters, to bindings, to runtimes, to concurrency, to scaling, to security, and more. So the term is meaningless in describing anything. Many "serverless" function/lambda systems are evolving into running arbitrary containers and now have come full circle to basically a modern version of PaaS, which is what they should've been called all this time.
There are clearly better options and tons of examples of poor naming causing annoyances and best and utter confusion at worst. We still live with the NoSQL hype repercussions and now serverless is following the same trend. It's not helpful and we can do better. What is a serious argument against that?
Data Lakes, Data Factories, and event hubs just sound like gobbledygook to me and if they are “exactly the same as thier underlying concepts”, those concepts mean no more to me than the term “serverless” mean to the uninitiated and I’ve been developing professionally for over 20 years. It’s the developers responsibility to pick up on industry jargon just like I had to do a year ago as the Dev lead when the company I worked for wanted to “move to the cloud”. I thought AWS was just a bunch of VMs a year ago.
I had heard of “Nosql” two years ago but I didn’t know what it was until I was hired to implement two projects on top of Mongo. Did I complain about the use of the term “NoSql” every time someone mention it? No, I learned Mongo inside out so I wouldn’t design something non scalable and non redundant.
You keep answering about yourself, I'm talking about the entire industry. For every one of you, there were 100 people who used MongoDB because its "fast, cool, noSQL".
It's great that you research, but many do not. Hype, jargon, and excessively misleading terms are real, and they make a measurable impact on productivity and confusion. This is why marketing and branding is so important when naming, and its why there should be an effort made to use better terms.
I still haven't heard a single argument on why we shouldn't do better, other than that you can handle it. Good for you, but that's not the point.
Concepts should be carefully named because this is not just jargon between a tiny handful of highly competent and super technical people; a vast number of devs and non-technical users will use these terms and it is in everyone's best interest to use descriptive and sensible wording.
Data lakes, data factories, event hubs are product names, not concepts, but they are either exactly the same as their underlying concept, or very closely related. However, as stated for the 3rd time, serverless is not. It's completely inaccurate and vague.
Where did you get that "serverless" means function as an entry point with 2 params? Every platform is different, from entry points to parameters, to bindings, to runtimes, to concurrency, to scaling, to security, and more. So the term is meaningless in describing anything. Many "serverless" function/lambda systems are evolving into running arbitrary containers and now have come full circle to basically a modern version of PaaS, which is what they should've been called all this time.
There are clearly better options and tons of examples of poor naming causing annoyances and best and utter confusion at worst. We still live with the NoSQL hype repercussions and now serverless is following the same trend. It's not helpful and we can do better. What is a serious argument against that?