This was a great read, and perfectly conveyed the combination of passion and anger of every WH player I’ve ever met has had.
Given the time, it’s hard not to view this same argument through the lens of AI. People who love crafting their creative works will still do it, even when AI can do it. They will still inspire others because they demonstrate what humans can do, and what we can aspire to.
This. As with all creative endeavours, part or even most of the enjoyment is the creative process, not the result.
Learning a skill and practicing it is still extremely enjoyable, even if a machine (or a factory) could do it better, faster, cheaper. The point is not the product, but the process.
Unfortunately, I've been to many coffee shops where the coffee tasted much worse than what a modern fully automated machine can produce.
And perhaps you have to be more nuanced - when TV's first hit the market, a wide-spread concern among film-makers was that it would kill movie theaters. The fear was that people would now only watch movies in the comfort of their homes. That didn't happen back then, but it pretty much did with the combination of big, flat-screen TVs and streaming services.
Not about quality. They want the experience of going to a cafe where the coffee is made and served by humans. These cafes exist along side automated coffee.
I don’t quite understand this comment, is it sarcastic? Drip coffee is already pretty automatic. Heck, I’ve been places where you just buy the cup and pump the coffee thingy yourself.
Compared to my home setup, (manual flair espresso press), most coffee shop espresso machines are quite a bit more automated. But I don’t begrudge them that automation, their arms would get too sore. And nobody is paying me to manually press my lever.
I mean "nobody" in the statistical sense. The number of people going to robot cafes is a rounding error compared with real cafe attendance. The fact that there are robot cafes and everybody (statistically speaking) is still going to cafes, proves the point exactly.
It sounds, as you point out, that he is aware of the tendency to typos and has an idea on how to guard against it. I’ve built up a similar portfolio of techniques and best practices to guard against my own shortcomings, and most of the friction I encounter is when the team I work with doesn’t have the same viewpoints on correctness and tests.
Languages like Python are the worst for exacerbating issues. Perl at least would parse the entire codebase and do some validation. Python doesn’t evaluate until runtime, meaning that unless you have 100% test coverage of all functions and branches a typo could cause an issue long after the process started.
As others have mentioned it sounds like you co-worker has good ideas. Adding test coverage, being stricter about configs (don’t ignore known keys, validate structure … as much as people hat XML, DTDs are an amazing help for catching config errors) are all things that will pay off down the road.
Long story short, instead of looking at your coworkers suggestions as a way to guard against their mistakes, take some time to understand that they live in a more chaotic worldview than you do, and have strong experience in dealing with it. Heck, put them in charge of QA processes. They sound like they’ve got the experience, and will feel better when that experience is appreciated.
Congrats on the progress thus far! I love aspirational languages, so please keep going.
That being said, as someone who struggles with maintaining large amounts of context when I’m debugging, I’d find context-specific execution hard to follow and debug. As a concrete example, the switch to an Admin context could appear far away from the call to GetPermissions without any obvious way to figure that out. Contexts end up being a sort of global state.
If you continue with this route, it would be nice if there was a way to print out the stack of the current contexts in play and where they were set in the code.
You're correct if Context is hidden or implicit (like Dependency Injection containers or ThreadLocals in Java), it becomes debugging nightmare.
To solve this, SFX treats the Context Stack as Explicit Data, not hidden magic.
1. Debugging: Because the runtime knows exactly what 'Reality' is active, we can print it. We are building a `Context.Trace()` tool that outputs something like:
`[Base Reality] -> [HolidaySale] -> [AdminMode]`
This tells you exactly why a method is behaving the way it is.
2. Layering: Yes, contexts are strictly layered (LIFO stack). If you activate `Situation A` then `Situation B`, the runtime checks `B` first, then `A`, then the Object itself. This allows for 'Behavioral Inheritance'—you can compose behaviors (e.g., `LoggingMode` + `SafeMode`) dynamically.
3. Scoping: Right now it is imperative (`Switch on/off`), but because SFX is indentation-based, we are working on block-scoped contexts for the next release:
Using AdminMode:
User.Delete() # Admin context
# Automatically reverts here
Except function colouring is a symptom of two languages masquerading as one. You have to choose async or sync. Mixing them is dangerous. It’s not possible to call an async function from sync. Calling sync functions from async code runs the risk of holding the run lock for extended periods of time and losing the benefit of async in the first place.
I don’t have anything against async, I see the value of event-oriented “concurrency”, but the complaint that async is a poison pill is valid, because the use of async fundamentally changes the execution model to co-operative multitasking, with possible runtime issues.
If a language chooses async, I wish they’d just bite the bullet and make it obvious that it’s a different language / execution model than the sync version.
I think this analogy is too extreme. That said, modern languages should probably consider the main function/threading context default to async.
Calling sync code from async is fine in and of itself, but once you're in a problem space where you care about async, you probably also care about task starvation. So naively, you might try to throw yeilds around the code base.
And your conclusion is you want the language to be explicit when you're async....so function coloring, then?
I still subscribe to Linux and Admin magazines, and look forward to getting them. They are nostalgic while still filled with genuinely useful information. There is something categorically different in the experience of sitting down and reading curated articles vs consuming an endless stream of updates. Both are worthwhile, and I’m glad both are options.
Plus, it’s a rare win/win of indulgence and plausible productivity.
I recently bought an electronics magazine for the first time in many years. Initially I flicked through and considered the articles in it kind of boring. But I think it’s just the absolute oversaturation of attention grabbing content online frying my brain.
The fact that you just have to read these medium form articles since that’s all there is for the month kind of resets your brain from just flicking through a million YouTube shorts.
Despite being Gen Z, our house wasn’t hooked up to the internet for most of my childhood and I remember spending ages analysing every single detail in the magazines I got. While now I have to actively avoid getting distracted and pulling out my phone.
I wasn’t aware of effects until I read the article, but I like the idea. The example you have is just an interface. Effects work a bit like boundary hooks. A pure function only works on things internal to its scope, and so it has no effects. An impure function might affect things outside of its scope, and may want to allow the caller to hook when those effects occur. Think a function that uses the gpu. That’s a side effect, and the function should be decorated to reflect that.
I’m guessing some languages would allow for checking to ensure that any induced effects are correctly noted and advertised so that the system as a whole can be more easily reasoned about.
The J language actually provides a lot of the niceties of the core Q / kdb functionality. It even has Jd, which is an on-disk columnar database. I don’t know if it counts as being commoditized, as the price in terms of time and effort to learn the language is still quite high.
You may want to check out J as a language. It is wonderfully terse and allows for point-free programming, and has all of the advantages you point to above.
Given the time, it’s hard not to view this same argument through the lens of AI. People who love crafting their creative works will still do it, even when AI can do it. They will still inspire others because they demonstrate what humans can do, and what we can aspire to.
reply