The word "need" is loaded and almost seems to be besides the point to me.
Your father-in-law wants to talk a human rather than self-serve. What's the problem with that? Honest question. The fact that he can self-serve is an undisputed fact. But why should he be expected to?
It might be more expensive for companies to offer the level of service that a lot of customers are asking for. If they want to offer that level of service they might have to raise their prices. If people want to pay those prices in order to get that level of service then who cares?
At thbe end of the day, a company is selling its products to people. And people come in all sorts of shapes and sizes and have all sorts of varied preferences.
There are people out there who do not want to own a smart phone. Who don't want to have to study a web page. They paid for something, they want it to "just work" and when it doesn't they want the burden of fixing it to be on the company they are giving their money to.
If a company doesn't want to offer that level of service, they don't have to. But they should expect to lose a certain demographic as a result. I don't think the chief complaint is that self-service options exist but that industries in general tend to chase trends. AI support can keep costs down for a company, great. But the trade-off for that is that there are people willing to pay more for human support and they often find themselves without options because everything always seems to be "all or nothing" with trends in business.
In most legal jurisdictions that I know of, kids aren't legally allowed to be able to access to pornography either. How is that working out?
The only way to even attempt to enforce these things is with government mandated age verification. Few people want that as it represents a massive violation of privacy and effectively makes anonymity on the Internet impossible.
You're not wrong, but that doesn't mean they weren't still in "growth" phase.
Their pricing, and their doubling down on account sharing policies over the last few years have shown that they are no longer in a growth phase.
I cancelled my Netflix account a few months ago because I had gotten the "You're not accessing this from your typical location" blocker. Even though I was trying to watch from my permanent residence and I was the account owner / payee.
The reason that happened was that my wife and I own two properties. We are happily married, not separated, but we just like our space... especially with two adult daughters who still live at home with one of their significant others also living in the house.
We are a single family "unit" but have two locations. Furthermore, my wife has sleeping issues and was using Netflix at night in order to fall asleep. To have to get me to check my email for an access code, was a total deal breaker since I would be fast asleep. So that cut her off from her typical usage of Netflix.
And the reason Netflix thought that I was accessing the service from a different location was that I hardly ever watched it. Every time I'd pull it up, I would spend more time scrolling for something to watch than actually watching anything.. and typically I'd just give up and go watch a 30m YouTube video instead.
So I was paying more, receiving less ... mostly had the account purely for my wife and daughters who watched it the most ... and then the final deal breaker was logistical barriers preventing me from being able to use what I'm paying for.
> when I'd actually written most of the Wikipedia article on said subject. The irony... Wikipedia doesn't just use unpaid labour, it ends up undermining the people who wrote it.
Surely it would be relatively easy to offer to show the edit history to prove that you actually contributed to the article? And, by doing so, would flip the situation in your favour by demonstrating your expertise?
The fact that you should have to is pretty annoying but also fairly edge case. And if a teacher or institute refuses to review that evidence then I don't think the credential on the table worth the paper it's printed on anyway.
> But, please, don't call it a "trade-off" - that implies that you're getting some positive benefits on both sides, which is inaccurate and misleading - you should be framing mutation as "safety price for necessary performance" - just like Rust describes unsafe blocks.
I would have agreed with that statement a few years ago.
But what I am seeing in the wild, is an ideological attachment to the belief that "immutability is always good, so always do that"
And what we're seeing is NOT a ton of bugs and defects that are caused by state mutation bugs. We're seeing customers walk away with millions of dollars because of massive performance degradation caused, in some part, by developers who are programming in a language that does not support native immutability but they're trying to shoe-horn it in because of a BELIEF that it will for sure, always cut down on the number of defects.
Everything is contextual. Everything is a trade-off in engineering. If you disagree with that, you are making an ideological statement, not a factual one.
Any civil engineer would talk to you about tolerances. Only programmers ever say something is "inherently 'right'" or "inherently 'wrong'" regardless of other situations.
If your data is telling you that the number one complaint of your customers is runtime performance, and a statistically significant number of your observed defects can be traced to trying to shoe-horn in a paradigm that the runtime does not support natively, then you've lost the argument about the benefits of immutability. In that context, immutability is demonstrably providing you with negative value and, by saying "we should make the runtime faster", you are hand-waiving to a degree that would and should get you fired by that company.
If you work in academia, or are a compiler engineer, then the context you are sitting in might make it completely appropriate to spend your time and resources talking about language theory and how to improve the runtime performance of the machine being programmed for.
In a different context, when you are a software engineer who is being paid to develop customer facing features, "just make the runtime faster" is not a viable option. Not something even worth talking about since you have no direct influence on that.
And the reason I brought this up, is because we're talking about JavaScript / TypeScript specifically.
In any other language, like Clojure, it's moot because immutability is baked in. But within JavaScript it is not "nice" to see people trying to shoe-horn that in. We can't, on the one hand, bitch and moan about how poorly websites all over the Internet are performing on our devices while also saying "JavaScript developers should do immutability MORE."
At my company, measurable performance degradation is considered a defect that would block a release. So you can't even say you're reducing defects through immutability if you can point to one single PR that causes a perf degradation by trying to do something in an immutable way.
So yeah, it's all trade offs. It comes down to what you are proritizing. Runtime performance or data integrity? Not all applications will value both equally.
We shouldn't forget that there are trade-offs, however. And it depends on the language's runtime in question.
As we all know, TypeScript is a super-set of JavaScript so at the end of the day your code is running in V8, JSCore or SpiderMonkey - depending on what browser the end user is using, as an interpreted language. It is also a loosely typed language with zero concept of immutability at the native runtime level.
And immutability in JavaScript, without native support that we could hopefully see in some hypothetical future version of EcmaScript, has the potential to impact runtime performance.
I work for a SaaS company that makes a B2B web application that has over 4 million lines of TypeScript code. It shouldn't surprise anyone to learn that we are pushing the browser to its limits and are learning a lot about scalability. One of my team-mates is a performance engineer who has code checked into Chrome and will often show us what our JavaScript code is doing in the V8 source code.
One expensive operation in JavaScript is cloning objects, which includes arrays in JavaScript. If you do that a lot.. if, say, you're using something like Redux or ngrx where immutability is a design goal and so you're cloning your application's runtime state object with each and every single state change, you are extremely de-optimized for performance depending on how much state you are holding onto.
And, for better or worse, there is a push towards making web applications as stateful as native desktop applications. Gone are the days where your servers can own your state and your clients just be "dumb" presentation and views. Businesses want full "offline mode." The relationship is shifting to one where your backends are becoming leaner .. in some cases being reduced to storage engines, while the bulk of your application's implementation happens in the client. Not because we engineers want to, but because the business goal necessitates it.
Then consider the spread operator, and how much you might see it in TypeScript code:
const foo = {
...bar, // clones bar, so your N-value of this simple expression is pegged to how large this object is
newPropertyValue,
};
// same thing, clones original array in order to push a single item, because "immutability is good, because I was told it is"
const foo = [...array, newItem];
And then consider all of the "immutable" Array functions like .reduce(), .map(), .filter()
They're nice, syntactically ... I love them from a code maintenance and
readability point of view. But I'm coming across "intermediate" web developers who don't know how to write a classic for-loop and will make an O(N) operation into an O(N^3) because they're chaining these together with no consideration for the performance impact.
And of course you can write performant code or non-performant code in any language. And I am the first to preach that you should write clean, easy to maintain code and then profile to discover your bottlenecks and optimize accordingly. But that doesn't change the fact that JavaScript has no native immutability and the way to write immutable JavaScript will put you in a position where performance is going to be worse overall because the tools you are forced to reach for, as matter of course, are themselves inherently de-optimized.
I ran a highly trafficked adult website for 18 years. In the early days, CDNs were unattainable for me and I managed my own rudimentary network by hosting bare metal servers in data centres around the world, using geo-ip aware DNS servers to send traffic to the closest data centre to them.
My most significant running expense was bandwidth cost. So I never switched to cloud since the bandwidth costs would have instantly bankrupted me. Cloudflare, on the other hand, was the single most significant development when it came to my bottom line. Adding a basic, $200 / month business account saved me thousands per month on bandwidth + server costs.
DDoS protection was just a nice perk.
Most small websites are hosting with cloud providers these days. If their websites are at all media rich (and most are these days), and those assets can be cached by a CDN ... the cost savings on bandwidth are not marginal. They are often the difference between being able to afford to host your website or not having one at all.
There are, of course, ways to optimize and reduce those expenses without a 3rd party CDN. But if Cloudflare still has their free plans for smaller traffic volumes, it is often a financial decision to use them over your cloud provider's CDN options.
My wife and I own a small theatre. We can process orders in-store just fine. Our customers can even avoid online processing fees if they purchase in-store. And if our POS system went down, we could absolutely fall back to pencil and paper.
Doesn't change the fact that 99% of our ticket sales happen online. People will even come in to the theatre to check us out (we're magicians and it's a small magic shop + magic-themed theatre - so people are curious and we get a lot of foot traffic) but, despite being in the store, despite being able to buy tickets right then and there and despite the fact that it would cost less to do so ... they invariably take a flyer and scan the QR code and buy online.
We might be kind of niche, since events usually sell to groups of people and it's rare that someone decides to attend an event by themselves right there on the spot. So that undoubtedly explains why people behave like this - they're texting friends and trying to see who is interested in going. But I'm still bringing us up as an example to illustrate just how "online" people are these days. Being online allows you to take a step back, read the reviews, price shop, order later and have things delivered to your house once you've decided to commit to purchasing. That's just normal these days for so many businesses and their customers.
I can understand that sentiment. Just don't lose sight of the impact it can have on every day people. My wife and I own a small theatre and we sell tickets through Eventbrite. It's not my full time job but it is hers. Eventbrite sent out an email this morning letting us know that they are impacted by the outage. Our event page appears to be working but I do wonder if it's impacting ticket sales for this weekend's shows.
So while us in tech might like a "snow day", there are millions of small businesses and people trying to go about their day to day lives who get cut off because of someone else's fuck-ups when this happens.
> But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has with web developers is backwards compatibility.
The fact that you put "contract" in quotes suggests that you know there really is no such thing.
Backwards compatibility is a feature. One that needs to be actively valued, developed and maintained. It requires resources. There really is no "the web platform." We have web browsers, servers, client devices, telecommunications infrastructure - including routers and data centres, protocols... all produced and maintained by individual parties that are trying to achieve various degrees of interoperability between each other and all of which have their own priorities, values and interests.
The fact that the Internet has been able to become what it is, despite the foundational technologies that it was built upon - none of which had anticipated the usage requirements placed on their current versions, really ought to be labelled one of the wonders of the world.
I learned to program in the early to mid 1990s. Back then, there was no "cloud", we didn't call anything a "web application" but I cut my teeth doing the 1990s equivalent of building online tools and "web apps." Because everything was self-hosted, the companies I worked for valued portability because there was customer demand. Standardization was sought as a way to streamline business efficiency. As a young developer, I came to value standardization for the benefits that it offered me as a developer.
But back then, as well as today, if you looked at the very recent history of computing; you had big endian vs little endian CPUs to support, you had a dozen flavours of proprietary UNIX operating systems - each with their own vendor-lock-in features; while SQL was standard, every single RDBMS vendor had their own proprietary features that they were all too happy for you to use in order to try and lock consumers into their systems.
It can be argued that part of what has made Microsoft Windows so popular throughout the ages is the tremendous amount of effort that Microsoft goes through to support backwards compatibility. But even despite that effort, backwards compatibility with applications built for earlier version of Windows can still be hit or miss.
For better or worse, breaking changes are just part and parcel of computing. To try and impose some concept of a "contract" on the Internet to support backwards compatibility, even if you mean it purely figuratively, is a bit silly. The reason we have as much backwards compatibility as we do is largely historical and always driven by business goals and requirements, as dictated by customers. If only an extreme minority of "customers" require native xslt support in the web browser, to use today's example, it makes zero business sense to pour resources into maintaining it.
ML has been around for ages. Email spam filters are one of the oldest examples.
These days when the term "AI" is thrown around the person is usually talking about large language models, or generative adversarial neural networks for things like image generation etc.
Classification is a wonderful application of ML that long predates LLMs. And LLMs have their purpose and niche too, don't get me wrong. I use them all the time. But AI right now is a complete hype train with companies trying to shove LLMs into absolutely anything and everything. Although I use LLMs, I have zero interest in an "AI PC" or an "AI Web Browser" any more than I have a need for an AI toaster oven. Thank god companies have finally gotten the message about "smart appliances." I wish "dumb televisions" were more common, but for a while it was looking like you couldn't buy a freakin' dishwasher that didn't have WIFI and an app and a bunch of other complexity-adding "features" that are neither required or desired by most customers.
It works well for everyone. The problem with government that is for and by the people, is that wealthy people are people too.
You're effectively saying that because you're worried about the "local wealth crowd" "capturing" government, you would prefer to make change in government more difficult and representation farther removed for everyone.
It's not clear how that would make it easier for the "non local wealth crowd" to affect change while it makes it harder for the "wealth crowd" ? Although maybe "local" is the key word here? I mean, that would imply that you're OK with global mega-corps capturing the federal level as long as they are not local companies. But I think I'd be straw-manning you to assume that's your position, and I'm not trying to strawman you. I'm just illustrating the logical conclusion of your idea if I take it at face value.
For what it's worth, I'm not a fan of protectionist economic policies. But if I were, I might offer that "local wealth" at least provides value at the local level (jobs, economic growth etc.) whereas global mega-corps have interests outside of the country.
In any case, it's not at all clear how making it less difficult for the "local wealth crowd" makes it easier for the "non local wealth crowd." As I see it, you just make government farther removed for everyone. Disadvantaging both groups equally. But if you're ideologically driven by a hatred of wealth and of capitalism, then maybe that's well understood and we are all sacrificial lambs on offer.
> But the design clearly is not fit for where our society is or the direction it is moving, people have much more affiliation with the national entity than with the state entity
For better or worse.
I would argue that government serves you much better the closer it is to you. A municipal government is going to be a lot more responsive to people who live in that city vs the State / Provincial level, who have a much broader constituency. And the State / Provincial level is going to be a lot more responsive to its constituency than the Federal level.
Politics is the direct result of the philosophy of a culture. The more culturally people identify as "American" instead of "Californian", "Texan", "Virginian" etc. the more you're going to see the scope of the federal level expand, because that's what "the people" are asking for.
The problem with democracy is that people don't always vote or act in accordance with their objective best interests.
And not to go off on a tangent, but the cultural attitude towards democracy itself is indicative of my point. Culturally people tend to equate democracy with "freedom" even though democracy is but a tool. A perfectly appropriate tool for certain things (should we spend the city budget on a new sporting stadium or upgrades to our roads?). But there are other matters that should never, under any circumstance, be put to a vote (ex: what groups of people have rights).
I switched to Mint (Mate) around 2012 or so because of radical UI changes made by Canonical. At the time, the "mobile revolution" was the big industry trend. Windows 8 had come out which was designed for touch screens (and people hated it) ... and Canonical released a new default desktop environment (I think it was Unity? Memory is fuzzy). It was shocking to me and when I complained about it, a friend recommended Mint.
The nice thing about Linux is that you have max choice. That can pose problems for new users who might be a bit overwhelmed but we shouldn't pretend that Canonical "owns" Linux or that everyone is necessarily going to land there. I recommend Mint when people tell me they're thinking of giving Linux a try. Haven't given Ubuntu a second thought in years.
Sure but I hope you get my point. Fighting takes effort, cooperation takes effort. Most people have other things to worry about and don't care about whatever it is you're fighting or cooperating over. People aren't motivated enough to try and sabotage the wikipedia articles of others. Even if they could automate it. There's just nothing in it for them.
> In my experience when humans are given the choice to cooperate or fight, most choose to cooperate.
Personally, my opinion of human nature falls somewhere in the middle of those two extremes.
I think when humans are given the choice to cooperate or fight, most choose to order a pizza.
A content creator I used to follow was fond of saying "Chill out, America isn't headed towards another civil war. We're way too fat and lazy for that."
More colloquially, people would say that Wikipedia could not be trusted because "anyone can edit the pages or write whatever they want."
Of course that's demonstrative of the genesis fallacy. Anyone can write or publish a book, too. So it always comes down to "how can you trust information?" That's where individual responsibility to think critically comes in. There's not really anything you can do about the fact that a lot of people will choose to not think.
I'm not worried that I'm going to lose access to V2. I'm worried that they are moving in the same rent-seeking direction that Adobe did that caused me to migrate to Affinity in the first place.
Creative tools are, to artists, like IDEs and git repositories are to coders.
Imagine you spend years getting very proficient at specific development tools, and you use a repo host like GitHub. One day your dev tools providers tell you that they are moving to a subscription model. You can continue to use the legacy stuff to access your source code. But if you choose to migrate to a new vendor, all of that legacy source code is now coupled to your old dev tools. Hopefully you have some sort of export -> import functionality so you can migrate. But this doesn't help the fact that you spent years honing your craft in a particular eco-system and now that ecosystem has deal breakers AND make it cumbersome and difficult to migrate away.
An artist has "source" files just the same as developers. They are the project files that have all of the raw layers and assets that would allow tweaks and revisions to be made.
For some artists, this can even make contracts difficult. I own a business, outsourced the creation of our logo to a local artist. Years down the road, if I wanted to ask her to send me the file in a different format, or make tweaks etc. she may charge me money for that, but it is totally on the table.
Imagine one day that happens and she has to tell me "Sorry, due to vendor lock-in and bullshit I had to switch to a different program and no longer have access to all of the project files that went into creating your logo."
Your father-in-law wants to talk a human rather than self-serve. What's the problem with that? Honest question. The fact that he can self-serve is an undisputed fact. But why should he be expected to?
It might be more expensive for companies to offer the level of service that a lot of customers are asking for. If they want to offer that level of service they might have to raise their prices. If people want to pay those prices in order to get that level of service then who cares?
At thbe end of the day, a company is selling its products to people. And people come in all sorts of shapes and sizes and have all sorts of varied preferences.
There are people out there who do not want to own a smart phone. Who don't want to have to study a web page. They paid for something, they want it to "just work" and when it doesn't they want the burden of fixing it to be on the company they are giving their money to.
If a company doesn't want to offer that level of service, they don't have to. But they should expect to lose a certain demographic as a result. I don't think the chief complaint is that self-service options exist but that industries in general tend to chase trends. AI support can keep costs down for a company, great. But the trade-off for that is that there are people willing to pay more for human support and they often find themselves without options because everything always seems to be "all or nothing" with trends in business.