True. But that’s advertising the product, not advertising in the product. It’s the latter that’s happening here. Imagine spending hundreds of thousands on a Ferrari, starting it up, and … finding an ad on the touch screen.
1,966 karma · joined July 31, 2018
> 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.
In a conventional FSM yes but not a statechart. Statecharts support parallel regions within a single state. You’d have 3 regions for your example: one waiting for each person. There would be 4 states total: one to wait on each person, each in its own region, plus the superstate. The superstate would exit when all 3 “waiting for person <x>” sub states exited, independent of their sequence.
I’m with you on Petri nets though, very helpful for modelling concurrent behaviour.
It highlights the often perplexing human tendency to reinvent rather than reuse. Why do we, as a species, ignore hard-won experience and instead restart? In doing so, often making mistakes that could have been avoided if we’d taken the time or had the curiosity/humility to learn from others. This seems particularly prevalent in software: “standing on the feet of giants” is a default rather than exception.
That aside, the article was thoroughly educational and enjoyable. I came away with much-deepened insight and admiration for those involved in researching, designing and building the language. Resolved to find and read the referenced “steelman” and language design rationale papers.
But it just moves the question to whether the theorems covered in the proof are sufficient. Underlying it all is a simple question:
Does the system meet its intended purpose?
To which the next question is:
What is the intended purpose?
Describing that is the holy grail of requirements specification. Natural language, behaviour-driven development, test-driven development and a host of other approaches attempt to bridge the gap between implicit purpose and explicit specification. Proof assistants are another tool in that box.
It's also one of the key motivators for iterative development: putting software in front of users (or their proxies) is still the primary means of validation for a large class of systems.
None of which is implied criticism of any of those approaches. Equally, none completely solves the problem. There is a risk that formal proofs, combined with proof assistants, are trumpeted as "the way" to mitigate the risk that LLM-developed apps don't perform as intended.
They might help. They can show that code is correct with respect to some specification, and that the specification is self-consistent. They cannot prove that the specification is complete with regards its intended purpose.
> It’s clear, people want to be addicted to social media
I'd say people are susceptible to addiction rather than wanting it. Suppliers of any addictive product - whether its tobacco, class A drugs, alcohol, gambling or social media - know that. Going too hard the other way into full prohibition is impractical because it starts to impinge on civil liberties: as a capable adult, why shouldn't I be able to smoke/drink/doomscroll instagram if I want?
That's why it's dificult; neither extreme liberty nor extreme prohibition is the answer. It's a grey area as GP notes. The trouble is it creates opportunities for people like Zuckerberg to exploit the middle ground and amass huge personal wealth paid for, in part, by the health detriment of those unable to self-regulate the addiction.
"Design Thinking" as a brand has codified that in several ways - not all successful. But the underlying principle is sound: there are plenty of examples of products/services that failed to address one or more of the 3 dimensions.
I found this quote from the linked article [0] more helpful:
> Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.
[0]: https://www.designorate.com/design-thinking-guide-what-why-h...
1. Coding assistants have emerged as as one of the primary commercial opportunities for AI models. As GP pointed out, LWN is the primary discussion for kernel development. If you were gathering training data for a model, and coding assistance is one of your goals, and you know of a primary sources of open source development expertise, would you:
(a) ignore it because it’s in a quaint old format, or
(b) slurp up as much as you can?
(a) carefully and respectfully leave it be, because you still get benefit from the previous content even though there’s now more and it’s up to date, or
(b) hoover up every last drop because anything you can do to get an edge over your competitors means you get your brief moment of glory in the benchmarks when you release?> it's really just a spec that gets turned into the thing we actually run. It's just that the building process is fully automated. What we do when we create software is creating a specification in source code form.
Agree. My favourite description of software development is specification and translation - done iteratively.
Today, there are two primary phases:
1. Specification by a non-developer and the translation of that into code. The former is led by BAs/PMs etc and the output is feature specs/user stories/acceptance tests etc. The latter id done by developers: they translate the specs into code.
2. The resulting code is also, as you say, a spec. It gets translated into something the machine can run. This is automated by a compiler/interpreter (perhaps in multiple steps, e.g. when a VM is involved).
There have been several attempts over the years to automate the first step. COBOL was probably the first; since then we've had 4GLs, CASE tools, UML among others. They were all trying to close the gap: to take phase 1 specification closer to what non-developers can write - with the result automatically translated to working code.
Spec-driven development is another attempt at this. The translator (LLM) is quite different to previous efforts because it's non-deterministic. That brings some challenges but also offers opportunities to use input language that isn't constrained to be interpretable by conventional means (parsers implementing formal grammars).
We're in the early days of spec-driven. It may fail like its predecessors or it may not. But first order, there's nothing sacrosanct about the use of 3rd generation languages as the means to represent the specification. The pivotal challenge is whether translation from the starting specification can be reliably translated to working software.
If it can (big if) then economics will win out.
He's also just released a book on hosting scale production Python apps [3]. Haven't read yet though would assume it'll get covered there in more detail too.
--
[1] https://talkpython.fm/blog/posts/we-have-moved-to-hetzner/
[2] https://talkpython.fm/blog/posts/update-on-hetzner-changes-p...
Ladybird currently has 8 full-time devs [1] and is making impressive progress on delivering a browser from scratch. Wise investment in small, focused, capable teams can go a long way if they're not chasing VC-driven Unicorn status (or in stasis as a Google anti-trust diversion).
That's not challenging your point though: in the face of competing budgets at US tech giants, EUR17Mn still barely registers above noise level. Nevertheless, it's a start. We can only hope it grows and doesn't get shut down by some political lobbying by the aforementioned US behemoths. A modest budget might actually help there - not yet big enough to cause concern to incumbents.
Kind of. The intent is good and the wording disallows some of the dark patterns. The challenge is that it stands square in the path of the adtech surveillance behemoths. That we ended up with the cesspit of cookie banners is a result of (almost) immovable object meeting (almost) irresistable force. There was simply no way that Google, Facebook et al were ever going to comply with the intent of the law: it's their business not to.
The only way we might have got a better outcome was for the EU to quickly respond and say "nope, cookie banners aren't compliant with the law". That would have been incredibly difficult to do in practice. You can bet your Bay Area mortgage that Big Tech will have had legions of smart lawyers pouring over how to comply with the letter whilst completely ignoring the intent.