Interesting idea. I feel like it could be productive to categorize operations by their result shape as well:
- Row select: From N rows, produce 0-N rows.
- Column select: From N columns, produce 0-N columns.
- Table add: From MxN and OxP tables, produce max M+OxN+P table.
- Table subtract: From MxN and OxP tables, produce min 0x0 table.
This line of thinking reveals some normally hard-to-see similarities, such as `groupby` and `dedupe` sharing the same underlying mechanism. (i.e., both are "collapsing" row selects.)
This is only "overcomplex" from a naive point of view.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
The real world is infinitely more standardized than virtual ones.
Physical space itself enforces a set of laws that make any two objects "compatible", regardless of any established interoperability agreements.
However, in software, there is no such constraint. Two randomly chosen software components are, in general, less composable than a chair and a galaxy.
This is the core reason why we have only been able to achieve interoperability in very specific domains. It's not because we're bad at design or planning --- it's because the space of ideas itself is simply so overwhelmingly large that it takes time and incredible coordination to get anything like pre-built IKEA blocks which fit together naturally.
So, building on this, we can view Beat Saber not as a music game, but as a *dance* game that figured out a reliable, precise way to track player movements.
It's interesting to note that similar movement-quantizing systems are at the core of numerous other hit games, most notably in Dance Dance Revolution but also to some extent Rock Band and Taiko no Tatsujin.
While I agree with the spirit of the post, I think that there are better and worse times to start something new, and in retrospect 2014 seems like it was one of those worse times. The period from 2014--2024 was an era where the sheer gravity of the big tech platforms crushed out innovative startups left and right. People with an extreme focus on product polish could succeed, like Slack (est. 2013) and Discord (est. 2015), but it feels like most of the tech-sphere was either just working on half-hearted products towards an inevitable acqui-hire, or fervently trying to mainstream blockchain in a wishful attempt to create an entirely separate, more open ecosystem.
I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do.
The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity.
So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already?
We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags:
1. `<sync value='variableName' />`: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case).
2. `<test if='variableName'></test>`: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy.
That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for `<template>`), the web platform would be well positioned to cover all others in time as well.
(You can toggle the layers to switch between no/some/many rat data. Sorry about the colors, best I could find. More purple = higher frequency of rat observations.)
Isn't it more likely to be the case that no one was willing to pay for the investigative journalism?
You see this everywhere. The clickbait is a funding source for the real work. Journalists almost never want to push garbage on the public --- they're usually forced to by management, either as an attempt at growth-at-all-costs or as a revenue source of last resort.
The big underlying factor is that so many software prices are artificially low because they're subsidized by collecting and making money off of users' personal data.
Unlike with physical goods, users don't know any "objective" ways to judge the fairness of software pricing. So they see (monetarily) free software everywhere and think that good software is cheap to make.
You can view the subscription/purchase debate as a second-order effect of people just not wanting to pay much for software, because they think that's what it's worth.
For comparison, US median house prices are up by 42% over the same period [1]. Hospitality prices (especially for traditional hotels, which raised rates by about 10%), are actually significantly trailing inflation.
Rather than scrolling through the obligatory endless speculation in the comments, I encourage all of you reading this to open up the section entitled "Long time coming" at the end of the article, and reflect on the fact that worthwhile science is hard and takes a long time to do, and nearly every incentive in academia or industry works in opposition to this.
How many other teams could we get working on projects in this field, were it not for funders preferring less risky but far less valuable studies?
I think this gets to the core of it. It's just not economic anymore.
My sense is that most of these family shops were started during the mid-20th century when the economy in developed countries was more accommodating to small business. Through decades of ever-increasing pricing pressure from giant multinationals, the most successful family operations could still keep their doors open because of the trusted reputation they had earned in their communities. But even that lifeline is increasingly imperiled as their best, longest customers age out and die, and are not replaced by younger customers because of constantly falling wages in real terms.
Yep, and it can be argued that this kind of complexity spectrum is the foundation of connoisseurship itself, in any domain. The journey from amateur to expert is one of becoming bored with simple, easy-to-understand things, and gradually seeking out more complicated things to satisfy one's curiousity.
Open source, historically speaking, is an implied social contract:
I as the developer do something nice for the world. I therefore hope that you, as the user, will pay it forward.
When this ethos is subverted by people who don't pay it forward, who just see "Free!" and unthinkingly take and take without ever thinking to give anything back, it rubs people the wrong way.
If we want progress, it's important to draw a distinction between the different effects of regulation.
Some regulation enforces the status quo, by helping entrenched interests use their power to crush potential innovators.
Other regulation restricts big players from abusing their dominance, and helps create a level playing field where innovation can succeed on its merits, no matter who's behind it.
It's not helpful to say that what we need is more rules, or less rules. What we need is rules that create a fair playing field.
Anyone remember the 1990s-2000s US-market civilian Hummer models, and how people at the time felt them to be absolutely massive? Well, the 2023 Chevy Suburban is a comparable size to the largest of those Hummers.
There are so many incentives for size creep, and improvements in occupant safety features and self-driving functionality just add fuel to the cycle, by making drivers feel like they can adequately control ever-bigger vehicles.
With the success of AI content generation for text (GPT-3 etc.) and images (DALL-E etc.), it seems inevitable that music will soon be targeted as well, if not already.
What's particularly interesting in the music sphere is that there are already well-established trends towards building a sort of ambient, atmospheric, generated soundscape. (For example, the famous "Lo-Fi girl" stream.) AI-generated content is a very natural progression here.
Regarding the broader pop music industry, a "GPT-3 for music" would likely further inequalize the relative power of labels and musicians. If people who control music distribution can easily make hit songs without needing to hire songwriters, arrangers, or performers, they surely will do so. I can imagine a lot of music-related occupations potentially having to pivot to rely much more heavily on live performances to make any money.
- Row select: From N rows, produce 0-N rows.
- Column select: From N columns, produce 0-N columns.
- Table add: From MxN and OxP tables, produce max M+OxN+P table.
- Table subtract: From MxN and OxP tables, produce min 0x0 table.
This line of thinking reveals some normally hard-to-see similarities, such as `groupby` and `dedupe` sharing the same underlying mechanism. (i.e., both are "collapsing" row selects.)