spinningslate
Joined 8 years ago
Joined 8 years ago
> They make great devices
They make great hardware. They used to make great devices - but a great device needs the whole user experience to be great. Ad-ridden UI does not make for a great device. Doesn’t matter if it’s first or 3rd party ads.
It’s a great shame. Apple used to be the design standard to aspire to. Now it seems to have embraced enshitification. All because the market needs that share price to keep growing. And lacking leadership good enough to find another way.
The open source desktop environments don’t have the profit motivator that drives the commercial alternatives. They’re driven to deliver their interpretation of great UI. We can each debate whether we agree with the vision or execution but that’s the motive.
If they can employ AI to help remove desktop friction - and it’s local and not shipping my data off to the surveillance machine - I’d be open to it.
In fact, if it could sort out KDE wallet’s amnesia for my wifi password, I’d give it a roll now…
1. Lack of closed loop between the "spec" and working code (your spec rot point). The Rational Unified Process(RUP) was a grossly inefficient, heavily manual undertaking. Mapping between artefacts - e.g. "Platform Independent Models" and "Platform Specific Models" was a manual, largely heuristic based approach. As a consequence the models were not generally kept up to date as the project evolved.
2. User experience mismatch. Developers were asked to create diagrams instead of writing code. Tool usability was poor ("write code with a mouse") and the artefacts didn't fit well with necessary tools like diffing and source code control (try diffing an xml file textually).
Coding agents have some potential for alleviating (1) in that they can read the result code and, at least to some extent, ensure spec and code are in sync.
(2) is more open. Some users - those proportionally more interested in solving the problem than designing/writing code - are more comfortable with natural-language-based specs and exploration. Those more experienced/comfortable with code will likely see those specs more akin to UML diagrams: a distraction from the real thing.
That's true but I'm puzzled by the decision rationale. It's undeniably a major undertaking to add first class, fine-grained processes to a language and its runtime. But time invested there gets the multiplicative upside that all language users benefit from the investment. Instead, Async/Await transfers the complexity to users of the language, as TFA describes.
As an Erlang and now gleam developer, I'm continuously grateful for the BEAM's support for fine-grained processes (note these are VM processes, not OS level). If I want to do things in parallel, I spawn a new process to do it. Do I want that concurrency because of io latency or parallel computation? Doesn't matter. Processes handle both. If I want an actor - a long(ish) lived "object" that responds to messages sent to it - I spawn it as a process. If I want to communicate between processes, I send a message. That's the only choice. No shared memory so no semaphores, locks and whatnot.
I never have to think "hmm, should this function be sync or async?" and reason about the transitive implications through the entire call stack. I write functions to calculate values. If I want function A to be called after function B in program 1, I write them sequentially. If I want to run them concurrently in program 2, I spawn them in separate processes. Concurrency is a decision at the calling site, not when writing the function being called.
One concurrency primitive that meets all the needs. The reduction in cognitive load is palpable compared to Python (the other language I use regularly).
The usual reaction is "yeah but performance". I've never found this to be an issue in real life. Sure there are benchmarks that show C/Rust/C#/whatever is faster, often meaningfully so. In practice, for my needs: never been a problem.
I'm ever more grateful for the elegance and consistency of the BEAM concurrency model. From an ergonomic perspective, Async/Await feels like a poor abstraction by comparison.
That's not to say the BEAM (or its languages) is the final word in concurrency. The strong encapsulation boundaries from Structured Concurrency[0] would be a useful addition. Though even there, Erlang's supervisor hierarchies provide a a similar mechanism. Dataflow is another interesting area (many task-concurrent design questions are essentially dataflow problems).
Even without improvement though I'd still take Erlang's approach over Async/Await every day.
> Colour is the namespace for values of A Distinguished Colour. Color is evidence that the source has arrived without a proper education.
Laughed unreasonably hard at that. Been a less than pleasantly civilised day at work, this was the relief I didn’t know I needed.
1. The hyperscalers are in a positive reinforcement loop. Despite any suggestions to the contrary they keep getting bigger. And can, er, “influence” government policy/officials and anything else needed to keep it that way.
2. The frontier labs and their investors. Another self-fulfilling reinforcement loop. Witness the circular gymnastics among OAI/Anthropic, Microsoft/Amazon and Nvidia
3. Data. No-one believes that Zuckerberg and co are going to say “great, we can just run the models on devices we don’t own and stop the surveillance economy because, y’know, privacy matters and we really care about mental health”.
And then there’s data centre locations and “yeah but jobs” even though your power bills are going up, and “why run your own data centre Mrs CTO, let us do it for you and save all that capex and those pesky employees you need to do it”.
Don’t get me wrong: I’m rooting for local, open weight/source models. But “hey look they benchmark well” is an unhelpfully narrow basis to forecast the demise of central hyperscaler hosting.
Exactly. Dairy farms optimise for milk production so favour cows that produce the most milk.
The market economy optimises for profit so favours those most willing/able to generate it. Zuckerberg, Musk, Thiel, Andreesen and co are products of the system.
Not OP but I can say with 100% truth and certainty that it wouldn’t matter how much money they offered - I would not work for meta. Some things matter more than money.
Phones and desktops are so radically different that your sedan/bulldozer analogy seems like shades of grey. It’s more like taking a Saturn V rocket to the local shop for a pint of milk.
I use streaming services. I like the flexibility and ubiquity of access. But my favourite music I still buy on cd or vinyl. Why? Because it means I’m not subject to the whims of a megacorp removing access and it means more goes to the artist. I’ve been buying music for 40 years and still listen to some of stuff I bought then. I hope to live long enough to do the same for the music I buy now.