OPINION: DVD is one of those technologies that dominated for barely a generation yet left a permanent cultural mark. It made high-quality video cheap enough for mass distribution, popularized the TV series boxed set, and encouraged its gluttonous consequence: binge viewing. Streaming and capacious storage have since pushed optical media toward irrelevance. There may no longer be a box, but the boxed-set mentality remains, and we still binge like Roman emperors. It is a genuinely new way of absorbing large quantities of information.
Now it is time to recognize a further evolution: the bingeable tech conference. Streamed conferences are nothing new, but few reward being watched from beginning to end. They offer too many talks on too narrow a subject, too much marketing flimflam, or too much variation in quality. The Goldilocks zone of quality, range, relevance, and intelligence is rare, but worth seeking out. This July delivered a near-perfect example: Software Should Work 2026.
The name supplies the plot arc. Software Should Work is about reliability in its broadest sense, because reliable software requires much more than making code that runs. It encompasses abstraction and formal methods, managing complexity, making the most of tools and processes, individual innovation, team culture, and the nuts and bolts of telling computers what to do. In just 13 videos, SSW creates a widescreen, high-definition, thought-provoking picture of the field today. You can watch them in a day, and once you start, you may not want to stop.
It would be unseemly to give too many spoilers. In such a concise treatment of a multifaceted subject, the talks that grab you will depend on your own interests and experiences. Consider dependencies, part of the calculus of reliability. So far, so dry. But Richard Feldman's talk compares web stacks from 1996, 2006, and 2026, revealing what looks like an inexorable multiplication of abstractions and dependencies. He then compares eight contemporary language and runtime websites: TypeScript, Node.js, Python, Ruby, Rust, Zig, Go, and Roc. The result is one of the more illuminating graphs you'll see this year.
Another thought-provoking contribution comes from Richard Hipp, creator of SQLite, one of the corest of the core technologies in everyday use. On its face, his account of how a codebase evolves in response to changing test methods sounds dry. It is also a personal journey, full of highs and lows, illustrating how reliability depends not only on the interplay between code and test design, but also on human motivation, creativity, flexibility, and doggedness. There is no shortage of technical detail either.
This is why SSW 2026 works so well. Its speakers have deep experience of software reliability, but were free to choose their subjects. The resulting mix of opinions, experiences, and approaches ranges from the mathematics of formal analysis to the importance of daydreaming and the dangerous myth of the superhero engineer. Reports from the language wars, AI WTFery, and arguments over whether Nix partisanship is justified are all present, delivered by people working on the front lines.
Most importantly, the conference explores the culture of reliability and what it means to say that software works. It feels like a proper symposium: an exchange of ideas about something that touches every part of the digital world yet is rarely considered as a whole. Commercial pressures can work against practitioners and customers alike, while the lack of a common language and agreed standards makes good practice harder to defend. Without reliability, everything falls apart. How to teach it, and where the discipline goes next, remain stubbornly difficult questions.
SSW 2026 provides a splendid and much-needed focus on all of this. Its blend of narratives and subjects means there is always something you did not know you needed to see, accompanied by the pleasurable sense of time well spent. Curiosity is richly rewarded. If you see software reliability as an ongoing drama – and if you don't, how are you still here? – block out a bingeing window. Software should work, but so should conferences, and this one is well worth the popcorn.
(Score: 5, Insightful) by turgid on Tuesday August 25, @08:53AM (23 children)
Software should be cool. It should use all the latest languages, libraries and frameworks. Especially Rust and Cargo Crates. If it's written in Rust it is guaranteed bug free. Or maybe Modern C++ with STL and Boost and Qt. Real Men(TM) program in C++ since Fortran is way old nowadays. I mean, even x86-64 assembly language (via NASM) is good. Everyone has an x86-64 machine these days unless it's ARM and then you can use an emulator. You can always write in Electron. Everyone has gigabit Internet these days so the 2GB binaries are not a problem and anyway everyone should get gigabit Ethernet.
Then there's Python. You can do real time embedded Raspberry Pi in Python nowadays and image processing. And AI. So there.
No one writes bugs anymore. They were from the days of C and Pascal and BASIC-A.
When everything's a crate, pipenv, cargo, electron you don't need tests. Somebody else better than you already wrote the code. Why bother testing?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by Rich on Tuesday August 25, @12:57PM (6 children)
God forbid. no! Simpler minds might be able to read a bit of the code and get the idea they could somehow tweak it. For legacy projects with Qt, at least convert all UI to QML and mingle that with the same amount of React.
WRT TFA, I feel it's an odd time for release, as AI just has gobbled up all the "box sets" and makes meaningful strides. I had an issue with a full-spaghetti legacy app on my desk yesterday that has resisted most attempts to change anything for 30 years. One special fringe feature stopped working. A guy at the customer site, wo had never really looked into the abyss of that codebase, had a detailed analysis within an hour (special characters in a filename had changed because of an encoding issue, but it was still referenced the old way in a script file - and that file was obfuscated). I'll have to ask him yet how he managed that, but it's either got to be black magic channeling the spirit of the elders who wrote the program (partially including mine, I bolted on some transcoding for UTF-8 15 years ago) - or their corporate Copilot subscription was smart enough to either decode the (primitive XOR) obfuscation itself, or had agentic means to run the accompanying decoder to look into the script file with the stale name. (Generously taking for granted that the AI would understand the spaghetti code and deduce the bug from a vague verbal description).
Anyway, the point of that anecdote is that it's probably too late to absorb all the stuff in the box sets to do it yourself when the AI just looks through your code, fixes the bugs, and also makes suggestions how to set up the process so the CI output will generate a shippable end product at any time. (Which still might have the occasional bug - but less bugs than if you'd do it alone). (Leaving us with the issue where the "senior" developers that have to look over the AI output come from when there's no point of having "junior" developers anymore).
(Score: 3, Informative) by turgid on Tuesday August 25, @02:29PM (5 children)
I was fishing for a Funny mod but I got Insightful...
Talking of vibe coding and AI, last week I was given some by a colleague. It was actually helpful in that it managed to make sense of some horrible example code and vague documentation. However, the code itself was very much in the style of the horrible examples (complete with all sorts of bugs and liberties taken).
Using the clues in the vibe code I was able to fill in the missing pieces in my own code. Without the bugs.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Insightful) by aafcac on Tuesday August 25, @02:33PM
There's a fine line between funny and insightful here, sometimes I think we need a parody or satire mod. But the list is already getting kind of long.
(Score: 3, Touché) by Freeman on Tuesday August 25, @02:40PM (3 children)
Worry not, I hit you up with the Funny mod.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by turgid on Tuesday August 25, @02:40PM (2 children)
Much obliged, sir.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Funny) by Freeman on Tuesday August 25, @02:51PM (1 child)
I think your thoughts were too coherent to pass the sniff test of sarcasm for most people. Well played.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Funny) by turgid on Tuesday August 25, @03:22PM
I'll remember to drink beer, wine and whisky first next time.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Insightful) by JoeMerchant on Tuesday August 25, @03:01PM (11 children)
Fortran is fine, for what it does. Unfortunately, cross platform GUI building packages for Fortran are sparse...
Qt was great in the 2005-2015 timeframe, IMO it has been falling from grace as the FUD/terror based license sales team runs around giving the company (and products it is associated with) a bad name and more complicated licensing story.
Before that I had a good run with the Borland VCL, until Borland intentionally self-torpedoed that. For me, the point of both of these wasn't the underlying C++/object model so much as it was a ready-to-wear set of GUI components.
Never was there a more appropriately named bag of slippery snakes than Python. IMO Python doesn't do anything of value other than provide an interface between other sometimes useful packages, with all the version control hell that inherently brings. Yes, snake charmers have their ways, but none terribly easy to pick up and practice.
>Somebody else better than you already wrote the code.
Indeed. A recent incorporate vs build custom debate came down to: control, do you want it? As long as you're happy with what the other guys built, satisfied that it will meet all present and future needs, confident that they won't defeature things you are using in the future in the name of "security", content to learn their idea of an "easy to use, logical API" then, sure - use those other people's code. But, for relatively simple yet important things? Why not invest the effort / maintenance to own it in-house instead of periodically re-training on how the other guys' stuff works, including forced retrain / potential re-implement cycles when they announce a "required security update" which seems to come roughly every other Tuesday from some vendors.
🌻🌻🌻🌻✌️ [google.com]
(Score: 1, Informative) by Anonymous Coward on Tuesday August 25, @04:24PM (6 children)
Python does one thing: provides a programming language so dumbed-down that even a moron can write code (and it shows). I once saw a 100+ Python program at work that did the job of a single line of bash, and everyone thought it was awesome.
(Score: 0) by Anonymous Coward on Tuesday August 25, @04:38PM
Yeahbutt it would run on Windows too, ammirite?
(Score: 5, Interesting) by janrinok on Tuesday August 25, @05:18PM (1 child)
So, could one say that you object to people who haven't had a career or formal training in software being allowed to program computers that they own?
Anyone can write crap software in any language. We know that. It is also natural that programmers will have a preference for a language - very often the first one which they feel that they mastered, and which they may have also spent a significant part of their life using. I don't think anyone will object to that either.
But as no-one wanted to help support the site which is dominated by Rehash and written in Perl, kolie decided to try something. He wanted to know how much worse the site would be if written in Python. So he has re-written parts of it in Python and tested them.
As a additional benefit, he discovered (and corrected) several logical errors in the code that were not obvious in Perl, but in Python were easier to identify.
Now I'm sure that we will have several people saying that we should have used [their favourite language] but those people didn't step forward and offer to help, did they? And if AC's assessment is correct that "even a moron can write code" then we shouldn't have too much of a problem finding people who will help in the future. Of course, I am being very optimistic here - people will complain but nobody is prepared to help.
(Score: 5, Funny) by turgid on Tuesday August 25, @07:30PM
Everyone knows that SNOBOL [wikipedia.org] knocks Perl into a cocked hat.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Touché) by aafcac on Wednesday August 26, @04:03AM (2 children)
It's called Python because it's not going to be winning any foot races.
(Score: 3, Insightful) by Bentonite on Wednesday August 26, @04:17AM (1 child)
Some snakes are actually pretty fast and could win a short foot races vs non-athletes, but it turns out the typical python has a top speed of ~3.2 kph, which explains the speed of Python.
(Score: 3, Insightful) by aafcac on Wednesday August 26, @07:04AM
Libraries written in C and using hardware extensions explain Python being fast when it is. Python itself is pretty slow for what it does.
(Score: 2) by jb on Thursday August 27, @07:30AM (3 children)
There, FTFY.
In almost every case, those kind of "framework" libraries cause far more harm than good.
Not that I'd particularly suggest Fortran for GUI work (it's a language that excels most in situations where getting the correct answer is appreciated as far more important than how it looks), but it couldn't possibly be any worse a choice than e.g. Javascript...
(Score: 2) by JoeMerchant on Thursday August 27, @12:16PM (2 children)
While we're discussing languages, refined forms of communication and recording thought, you bring up an intentionally misleadingly named system of grunts and handwaves developed for use while traveling inside browsers... that's more of a straw-donkey than a straw-man.
🌻🌻🌻🌻✌️ [google.com]
(Score: 2) by jb on Friday August 28, @07:11AM (1 child)
I would tend to agree with you ... except that sadly I've actually seen non-trivial things (in production!) implemented in standalone javascript, with no browsers involved at all (but still just as many third party libraries...). Goodness knows why, but some people do that.
Yes it's horrific to behold. Usually the conversation goes something like this: "Our guy left and he left behind this big tangled mess of js, will you clean it up for us?" "No, that would just be throwing good money after bad, but show me the original documented requirements and we'll implement a more reliable replacement for you" "The what?" "Oh, he didn't do that either? Then what you have is no more than a toy. Let me explain how we go about designing a tool ..."
(Score: 2) by JoeMerchant on Friday August 28, @11:37AM
Qt Quick / Javascript was a huge disappointment to me. The Qt widgets system was close to perfect, one of the easiest to use systems I ever worked with, Qt Quick struggled to be useable at all.
🌻🌻🌻🌻✌️ [google.com]
(Score: 1) by khallow on Wednesday August 26, @03:43AM
(Score: 2) by Bentonite on Wednesday August 26, @04:11AM (2 children)
This bait post was believable until I got about half way through - good job.
(Score: 2) by arslan on Thursday August 27, @12:19AM (1 child)
Half way through? First line, 4th sentence already sent red flags up my wazoo...
(Score: 2) by Bentonite on Thursday August 27, @03:23AM
Such quoted text is the honest opinion of many Rust pushers, so I was typing up about how rust forces 12-160x the bugs, by requiring 12-160x the lines to do the same thing as GNU C (I measured), but then I read the rest.
(Score: 2) by driverless on Wednesday August 26, @12:22PM
Alongside the existing ones, don't miss Filip Pizlo's talk [youtube.com].